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ABSTRACT 



This thesis is a study of the regulations and directives that apply to the 
acquisition of Automated Data Processing systems for the United States Coast Guard. 
The original standard terminal acquisition for the Coast Guard in 1981 was intended to 
provide the Coast Guard with state of the art microcomputer capabilities. It was also 
an attempt at standardization to avoid a proliferation of noncompatible computer 
systems. A comparison of the original standard terminal acquisition process with the 
current applicable guidelines and regulations will provide a number of 'lessons learned' 
as well as a basic framework for similar acquisitions in the future. 
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I. INTRODUCTION 



A. PURPOSE 

In 1981 the Coast Guard contracted for a service-wide standard microcomputer 
capability and its support. That contract is about to expire. In the interest of 
continuing to provide the Coast Guard with the microcomputer capabilities and 
support which have become an integral part of Coast Guard operations and support, 
procurement of hardware, software, maintenance, training and other support services 
must be completed prior to the expiration of the current contract. The following 
excerpt from a Coast Guard policy document describes the need for this thesis: 



The original standard terminal contract was extremely difficult to manage for the 
first vear and a half, mostlv due to the Coast Guard's inexperience witffan ADP 
procurement that reached s'o deeplv into the organization. This was the first time 
ADP capability was made available to the majoritv of the Coast Guard, and the 
contract provisions were not adequate to ensure sufficient support to the user. 
To avoid similar problems in the administration of the follow-on contract, the 
project staff shall place a heavv emphasis on seeking lessons learned in the past, 
and incorporating them into the strategy of the new procurement. Experts in 
many functional areas must be involved"such as G-FCP (Office of Comptroller, 
Procurement Division). G-FQA (Office of Comptroller. Qualitv Assurance 
Division). G-PTE (Office of Personnel,' Training and Education Division), G-TDS 
(Office of Command. Control and Communicalions. Data Svstems Division). G- 
TES (Office of Command. Control and Communications, Electronics Division). 
SMEF (Svstems Management and Engineering Facility) and all Operating and 
Support Program Managers. In addition, involvement of persons with firsthand 
knowledge of the problems in the original contract would help to avoid the same 
problems the second time around. [Ref. 1: p. STMP-20] 



This thesis will attempt to satisfy the lessons learned requirement from the Data 
Systems Division (G-TDS) Project Officer's point of view. Finally, the policy 
statement quoted above is stated in a very negative way. It suggests that the earlier 
problems should be avoided. However, it makes no mention of the strengths and 
positive points of the original acquisition. In the conclusions portion of this thesis, the 
strengths to be emphasized as well as the problems to be avoided will be discussed. 

B. METHODOLOGY 

An extensive literature search of applicable Department of Transportation, Coast 
Guard, General Services Administration, and Office of Management and Budget 
regulations, orders and directives was performed to determine the acquisition process 
prescribed for ADP resources To provide insight into the original standard terminal 
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acquisition process, interviews and questionnaires were used to obtain information 
from the participants in that project. Questionnaires from other studies on the 
standard terminal were also used. The members involved with the current project for 
recompetition of the Coast Guard standard terminal provided an extraordinary amount 
of knowledge of and insight into the acquisition process. Although a significant 
amount of the original life cycle documentation for the first project was not located in 
the acquisition file, the interviews have provided substantial information toward filling 
documentation gaps. 

Comparison of the original standard terminal acquisition with the current 

regulations may seem like an unfair and meaningless evaluation. However, this thesis 

was prepared in that very’ manner for several reasons. First, obtaining the applicable 

regulations as they existed at the time of the original acquisition would be a significant 

if not impossible research task. Next, microcomputers were a relatively new 

* 

technology bursting onto the scene at that time, and their impact was not completely 
evaluated or anticipated by those organizations that mandate regulations and establish 
procedures. Some of the directives and regulations did not even exist at the time of the 
original acquisition. Finally, the intent of this thesis is to provide a constructive 
'lessons learned' type of evaluation approach, to avoid the pitfalls and emphasize the 
strengths of our past efforts. This thesis will provide an acquisition model upon which 
acquisition planners and managers can use to base similar acquisitions. 

Following the current applicable rules and regulations while avoiding the 
problems of the past should be a major goal for any type of acquisition undertaken by 
the Coast Guard. 

C. THESIS ORGANIZATION 

• CHAPTER I. Introduction - A description of the thesis. 

• CHAPTER II. Background - The reasons behind the acquisition of the Coast 
Guard Standard Terminal. 

• CHAPTER III. Budgeting - A tip of the iceberg introduction to the Coast 
Guard planning, programming and budgeting svstefn for command, control and 
communications/ information resources management (C3, IRM). 

• CHAPTER IV. Acquisition Framework - The significant elements that 
comprise the acquisition process for ADP resources are^each briefly described in 
the early sections of this chapter. Developing an acquisition model by putting 
these elements together is the purpose of the final section. 

• CHAPTER V. Acquisition - The actual acquisition process used bv the Coast 
Guard for the standard terminal. 

• CHAPTER VI. Conclusions and Recommendations - Brief discussions of 
significant points considered as a result of research into the standard terminal 
acquisition process. 
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• APPENDICES - Enclosures taken from numerous government sources on the 
contents and preparation of acquisition documentation and reports. 

• LIST OF REFERENCES - A sequential list of sources cited or paraphrased in 
the body of the thesis. 

• BIBLIOGRAPHY - Selected sources which proved helpful in the research 
process. 
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II. BACKGROUND 



During the late 1970's the Coast Guard began developing what was later to 
become the U.S. Coast Guard Information Resources Management Architecture. The 
plan was based on the following goals [Ref. 2: p. 2-2]: 

• Intelligent Terminals to provide a vehicle for local processing, original data 

entry, and access to the network(s) 

• The Communications Network to provide connectivity 

• Data Base Technology to control the data resource 

• Integration of the parts into a whole. The parts are: 

a. Plans 

b. Budgetary Action 

c. Human resources (including training) 

d. Applications software to perform specific tasks 

e. Standard software packages to provide common user capabilities and 
interfaces 

f. Support facilities such as Coast Guard laboratories and Supply Center to 
provide unique services such as hardware and software support. ' 

The standard terminal became the intelligent terminal, one of the building blocks, 
upon which the architecture plan is based. A contract for communications network 
services was let during FYSO, one year before the standard terminal contract. A 5 year 
service contract with GTE Telenet provided the telecommunications medium along 
with other Government networks. The standard terminal hardware and software 
provided the local networking capability. 

Data base technology, another major part of the plan, refers to the concept that 
every user does not require that his/her data be stored and/or maintained locally. 
Rather, the data may be available at another source where it is entered or maintained. 
Ideally, the technology and methods to access that data would be transparent to the 
user. Providing access to data in central databases allows a practical and economical 
means to insure data integrity. Every user does not require a separate copy of the 
database or the resources (time, personnel, machine, money) to maintain current and 
accurate data. The goal that data need only be entered once and eventually 
maintained by a single activity, benefits the Coast Guard as a whole. The Joint 
Uniform Military Pay System (JUMPS) is a prime example. JUMPS has a central 
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database where pay data is stored and maintained on Coast Guard members. 
References to pay are all done through the central database. 

The basic goal of the IRM architecture is to promote resource sharing. Figure 
2.1, reproduced from Commandant Instruction M 3090.1, is a diagram depicting the 
IRM architecture. It shows the capabilities and methods available to the Coast Guard 
for information transfer and access. 

Clusters of standard terminals are spread throughout the architecture as end 
user's tools. They are represented as terminals in the diagram. 

The information centers at Coast Guard Headquarters and District offices are 
tasked with carrying out support functions for users. The support includes 
recommending use of the proper hardware and software, enforcing standards, and 
dealing with common user problems and requests, to name a few. 

The networks displayed on the diagram are the primary method of data transfer 
utilized by the Coast Guard. AUTODIN. DDN (Defense Digital Network) and 
NADIN (Federal Aviation Administration's National Airspace Data Interchange 
Network) are Government networks. Public networks include FTS, the public switched 
network (telephones), and the value added network of GTE Telenet. Coast Guard 
leased lints"are dedicated data lines still used in some applications. The polled network 
is used for low to medium speed store and forward communications. Store and 
forward communications are most common in the message traffic system, where 
messages may be sent from unit to unit. 

A prime example of a system complying with the IRM architecture is the Marine 
Safety Information System (MSIS). It is depicted on the architecture diagram. MSIS 
is one of the major applications that drove the standard terminal requirements in its 
early planning stages. It is a system built around an extensive base of information 
about commercial vessels and marine safety. It provides licensing, inspection and 
documentation information nationwide. Standard terminals connect Headquarters, 
District offices, Marine Safety Offices (MSO), Captain of the Port offices (COTP), 
Marine Inspection Offices (MIO) and Marine Safety Detachments (MSD) to the MSIS 
host via networks. Other major applications such as JUMPS (Joint Uniform Military 
Pay System) and PM IS (Personnel Management Information System), for example, 
exist and utilize the IRM architecture in the same manner as MSIS. 

Coast Guard units include airstations. MSO's. groups, coastal search and rescue 
stations, communications centers, cutters and aircraft. Clusters of standard terminals 
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are typically found at most units. Clusters allow interconnection of offices and 
divisions at those units. 

A major goal of the Coast Guard C3/IRM is to maintain horizontal and vertical 
compatibility of its IRM resources. Horizontal compatibility means the ability of 
information to be used from station to station, from unit to unit. Vertical 
compatibility is being able to pass information from smaller subordinate units to larger 
higher level units. The reverse is also desired. 

The standard terminal was originally intended to be a Coast Guard wide standard 
data entry terminal. ADP capability was centralized in large facilities at that time. 
Use of a single, easily recognizable, piece of hardware would reduce the training and 
familiarization time necessary for personnel using those ADP facilities. 

If all access equipment is configured with standard modules, if the method of 
discoursing with the computer is the same, and if the method of computer data 
displav is common throughout all computer facilities and applications, then the 
problem of multiple ADR facilities and vendors does not alfect the user. If the 
user sees a consistent access scheme on a -computer terminal displav screen, and 
discusses and enters data to all computers in a consistent format, he or she need 
not be concerned about the make, model, or location of the computer being 
accessed. [Ref. 3: Sec. F. 1.2.2] 

The standard terminal was developed into a high capability microcomputer with the 
ability to satisfy most of the Coast Guard's needs at that point in time and well into 
the future. 

Office automation was not a buzz word during the late 1970's when the 
requirements for the standard terminal were developed. The Coast Guard built office 
automation capabilities into its contract when it decided that local word processing, 
telecommunications, and local networking should be requirements for its systems. 
Local networking (clustering) gives several workstations in a relatively close area the 
ability to share peripheral devices and, most importantly, share data. 
Telecommunications allow remote data entry and data transfer between clusters, and 
from workstations to larger ADP facilities. 

Applications development software such as Pascal, Cobol and Fortran were 
included on the specification. Others, such as database capabilities, for local data entry 
and manipulation were also required. Each site had a standard set of software 
delivered with its hardware. 
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U.S. Coast Guard Information 
Resources Management Architecture 




Figure 2.1 Information Resources Management Architecture. 
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III. BUDGETING 



Budgeting for any large project is a process that must begin well in advance of 
the time that funds will actually be obligated for that project. This chapter will provide 
an overview of the planning, programming and budgeting system the Coast Guard's 
Office of Command. Control, and Communications (G-T) uses for information 
resources management (IRM) resources. 

The Commandant has responsibility for an approved Coast Guard program. The 
Chief of Staff at headquarters coordinates the activities of program directors, who rely 
on program managers, to develop the various programs that support the basic 
objectives of the Coast Guard [Ref. 4: p. 1-2]: 

• To minimize loss of life, personal injurv. and property damage on, over, and 
under the high seas and waters subject to U.S. jurisdiction. 

• To facilitate waterborne activities in support of national economic, scientific, 
defense and social needs. 

• To maintain an effective, readv, armed force prepared for and immediately 
responsive to specific tasks in time or war or emergency. 

• To assure the safety and securitv of vessels and of ports and waterways and 
their related facilities. 

• To enforce federal laws and international agreements on and under waters 
subject to the jurisdiction of the United States' and on and under the high seas 
where authorized. 

• To maintain or improve the quality of the marine environment. 

• To cooperate with other governmental agencies and entities (federal, state and 
local) to assure efficient" utilization of public resources and to carry out 
activities in the international sphere where appropriate in furthering national 
policy. 

General policy guidance is provided for the next 25 years by the Commandant's 
Long Range View. Future Coast Guard missions and activities are anticipated through 
the forecasts provided in the document. Headquarters and field level planning are all 
based upon the Commandant's forecasts. The Long Range View', however, is not a 
plan, it is a policy statement. 

Requirements from which the Coast Guard develops its budget come from many 
sources. Figure 3.1 illustrates the inputs to the planning database. 

Operating program plans and support program plans are extracted from the 
Commandant's Long Range View. With this extraction, planning is brought down to a 
more manageable time frame of 5 years. Operating program plans (OPP) and support 
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program plans (SPP) are developed by operating and support program managers. 
Operating program managers are those officers overseeing programs such as search and 
rescue (SAR) and enforcement of laws and treaties (ELT) which make up the various 
missions that the Coast Guard performs. Support programs are those programs that 
support the missions of the Coast Guard, such as telecommunications and engineering. 

It is at the program director/manager levels that policy is converted into plans, 
programs and budgets. Command, control and communications is one of the Coast 
Guard support programs. As mentioned earlier, a five year support program plan 
(SPP) is used to translate formal Coast Guard objectives into programs. The program 
director for this support program is the Chief, Office of Command, Control and 
Communications (G-T). His deputy office chief (G-Td) is the program manager for 
command, control and communications programs. 

District Commanders and Commanding Officers of headquarters units also take 
the Commandant's forecasts and translate them into planning proposals (PP), 
development plans (DP). Letters with recommendations and suggestions may also be 
used to provide input to the requirements database. Planning proposals are the initial 
input for submitting a field originated project into the planning, programming and 
budget system. Approval of a planning proposal shows that the project is of 
significant importance to proceed to the resource change proposal (RCP) phase. 
RCP's are budget requests. They will be discussed later in this section. 

Requirements for information resources management resources are described in 
terms of functions, processes, activities, information requirements, and entities which 
define the anticipated system. ADP systems should also be submitted to the Coast 
Guard ADP Plan, which is input to the ADP obligation ceilings set for the various 
agencies of the federal government by the Office of Management and Budget. 

Coast Guard requirements come from several other sources. The Departments of 
Defense and Transportation may provide suggestions or direction to the Coast Guard. 
Research and technology from outside the Coast Guard are external sources of input. 

Figure 3.2 graphically shows the process which is followed to develop C3/IRM 
requirements into approved budget items. 

C3/IRM requirements from the planning database are forwarded to the Office of 
Command, Control, and Communications, Planning and Policy Division (G-TPP). The 
Coast Guard C3, IRM Plan is developed from that data. The C3/IRM Plan addresses 
the applicable requirements which may have come from shorter time frame support 
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plans. Coast Guard goals and strategies for command, control and 
communications/information resources management for the next 20 years are outlined 
in the C3/IRM Plan. 

The direction in the C3/IRM Plan provides input to the Coast Guard ADP Plan 
and is the source of the C3 Support Plan (GAT SPP) which describes the proposed 
ADP and telecommunications systems for the next 5 year time frame. Systems 
requiring research and development effort are input to the R&D Support Program Plan 
(GRD SPP). Others are passed to the C3 requirements document which provides 
detailed schedules for replacement and acquisitions of new capital resources. 

Budget requests are submitted in the form of resource change proposals (RCP). 
Besides cost estimates the RCP includes information on personnel resources which will 
be required, expected benefits and impact on other programs. Three different funding 
types are: (1) operating expenses (OE) are the funds with which the Coast Guard 
carries out its activities during the budget year: (2) acquisition, construction, and 
improvement (AC&I), multiyear funding for large projects and capital investments; and 
(3) research, development, test and evaluation (RDT&E), research and development 
projects. Some requirements will automatically have RCP's approved. Others, 
however, will require determinations, prioritized justifications, be prepared by the 
responsible program manager. The Commandant later decides which of these become 
RCP's. Approved RCP's are then used to formulate the Coast Guard budget. 
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[Ref. 2: p. 2-13] 



Figure 3.1 Coast Guard Long Range Planning. 
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[Ref. 2: p. 2-14] 



Figure 3.2 Budget Process for C3 IRM. 
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IV. ACQUISITION FRAMEWORK 



This chapter describes several of the most important topics concerning large 
ADP acquisitions. They are the ADP Plan, the Department of Transportation's 
implementation of the Office of Management and Budget's A-109 acquisition process 
for major systems, the secretarial review process for acquisitions of significant interest 
to DOT, and the procurement authority for ADP resources. Although it is improbable 
that a Coast Guard ADP acquisition would meet the life cycle cost or R&D cost 
criteria of a major system, a discussion of the A-109 process is important. A secretarial 
review designation may require the acquisition be done following a scaled down A-109 
process. 

Following a brief presentation of the topics mentioned above, an acquisition 
model is proposed. The model is to be used by the team involved with overseeing the 
acquisition. Those involved with particular projects along the way will be concerned 
with their process in much greater detail, therefore the overall acquisition model will 
not be of particular benefit to them. However, everyone involved with the acquisition 
should be aware of the major project milestones and how those milestones can be 
affected by their progress and efforts. 

A. ADP PLAN 

Planning for ADP resources in the Coast Guard is accomplished by reporting 
ADP systems and proposals in the Coast Guard ADP Plan. The ADP Plan provides a 
near to mid term planning horizon as to where the Coast Guard should or will be in 
terms of ADP systems and capabilities in the next 5-10 years. Reporting of all ADP 
requirements is mandatory', regardless of the system cost. Larger systems that are 
being developed will be reported in the ADP Plan over a number of years, beginning 
with its concept formulation, continuing through its implementation. Submissions to 
the ADP Plan must be made to Commandant (G-TPP) by 1 May of each year. 
Commandant Instruction M5230.8(series) is the Coast Guard ADP Plan. 

Funding information for all systems and proposals is included in the ADP Plan. 
Summary budget data is compiled for all operating agencies by the Department of 
Transportation into the DOT ADP Plan, which satisfies DOT'S planning requirements 
for ADP as well as reporting requirements specified by the Office of Management and 
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Budget (OMB). 0MB takes the data from the DOT ADP Plan and sets an ADP 
Obligation Ceiling for the Department of Transportation. DOT, in turn, sets an ADP 
Obligation Ceiling for the Coast Guard, which in turn sets unit ceilings for units 
reporting in the Coast Guard ADP Plan. Units submitting input to the ADP Plan 
must identify the source of funds for their projects. RCP's for AC&I, OE and RDT&E 
funds are submitted by operating and support program managers for larger ADP 
systems. 

System proposals reported in the ADP Plan are not necessarily approved simply 
by their appearance in the plan. Projects with estimated life cycle costs is excess of 
S50,000 require the approval of Commandant (G-T). In cases where life cycle costs are 
expected to exceed the Coast Guard's blanket delegation of procurement authority of 
S50,000 for ADP resources, DOT approval must be sought. The recommended method 
to request approval- of a system is to submit a request for advance approval with the 
annual ADP Plan submission. The advance approval request should appear in the 
ADP Plan one year before approval is necessary to allow for DOT review. Systems 
not using the advance approval process should expect delays in receiving DOT 
approval. Those systems not appearing in the ADP Plan with acquisition life cycle 
costs in excess of S50,000 will require DOT approval, but will only be considered on a 
case by case, time available basis. Consolidation of all proposed systems and requests 
for approval provides the reviewing authorities with an overall picture of where the 
Coast Guard is going with ADP and information systems. 

B. MAJOR SYSTEMS 

OMB Circular No. A-109, Major System Acquisition, specifies the procedures to 
be followed during the acquisition process of systems designated as major. Agencies of 
the federal government are mandated to implement the A-109 process for their major 
acquisitions. However, each agency is allowed to determine the criteria of systems that 
do or do not qualify as major systems. Major systems acquisition programs are those 
programs that (1) are directed at, and are critical to, fulfilling a Departmental mission, 
(2) entail the allocation of relatively large resources, or (3) warrant special management 
attention [Ref. 5: p. 2]. The Department of Transportation's (DOT) major systems 
criteria are: 

• Total system acquisition cost exceeds SI 50,000,000; or 

• Research and development costs in excess of S25,000,000; or 

• DOT secretarial review designates the system as a major system. 
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Acquisition costs are those costs incurred over the life of the system starting with the 
concept formulation up to and including implementation. Acquisition costs do not 
include system maintenance costs. 

Input for budget planning for new and ongoing acquisitions which meet the 
above dollar criteria for major systems is submitted to the Department of 
Transportation, Assistant Secretary for Budget and Programs by the first of May each 
year. For proposed systems, a memorandum on the major systems candidate, 
Appendix B, and a mission need statement (MNS), Appendix C, are required inputs. 
The memorandum on the major systems candidate is basically a one page condensation 
of the mission need statement. However, it also includes a recommendation as to 
whether or not the project should be designated a major system. 

The major systems acquisition process is broken down into a series of more 
manageable subprocesses separated by decision points. They are called Key Decisions 
in the Department of Transportation's implementation of Circular No. A-109's 
procedures, described in DOT Orders 4200. 14( series) and 4200.9(series). The Deputy 
Secretary of Transportation retains the approval authority at each Key Decision point 
unless specifically delegated. Recommendations at each Key Decision are provided to 
the Deputy Secretary from the Transportation Systems Acquisition Review Council 
(TSARC). The membership of the TSARC is: 

• Deputy Secretary (S-2), chairman 

• Assistant Secretary for Policy and International Affairs (P-1) 

• Assistant Secretary for Budget and Programs (B-l) 

• Assistant Secretary for Governmental Affairs (1-1) 

• Assistant Secretary for Administration (M-l) 

• Assistant Secretary for Public Affairs (A-l) 

• General Counsel (C-l) 

• Director, Office of Installations and Logistics (M-60), TSARC Executive 
Secretary. 

Missions are those responsibilities mandated or delegated to an agency for 
satisfying a national need. The mission need statement describes a mission deficiency 
or opportunity to more effectively or efficiently perform mission responsibilities. It is 
important to recognize that the MNS is not intended to propose a solution, but merely 
to document a perceived need. Format for the MNS is provided in Appendix C. 



OMB Circular No. A- 109 requires a continuing analysis of current and forecasted 
mission capabilities, technological opportunities, overall priorities and resources 
that are involved. When the'" analysis identifies a deficiency in existing agency 
capabilities or an opportunity to 'establish new capabilities in response to a 
technologically feasible opportunity, this will formally be set forth in a mission 
need statement. [Ref. 6: p. 8] 

The original standard terminal acquisition was an opportunity for the Coast Guard to 
establish new capabilities for both operations and support because of a relatively new 
technology, microcomputers. It was so new, the Coast Guard and the Department of 
Transportation were not quite sure how to proceed with the acquisition. 

Budget estimates included in the mission need statement determine how DOT will 
choose to manage the acquisition. The secretarial review process will be discussed in a 
later section. 

Approval of a mission need statement by the Deputy Secretary is a prerequisite 
to proceed further with the project. Following approval of the mission need statement 
(MNS) a project officer (PO) should be designated as soon as possible. The project 
officer should draw up a charter, basically a contract between the PO and his her 
superiors outlining the job description, responsibilities, and authority. The charter is 
approved by the Chief of Staff (G-CCS). The project officer reports directly to the 
program director. For ADP acquisitions the project officer reports to the Chief, Office 
of Command, Control and Communications (G-T). The responsibilities of a project 
officer include [Ref. 4: p. 16-3]: 

• Ensuring the project is responsive to mission needs, as stated in the mission 
needs statement (MNS) 

• Develop project objectives 

• Establishing project schedules 

• Providing necessary budget documentation 

• Preparing and updating the acquisition paper (AP) and other documentation, 
andr 

• Executing approved AP milestone schedules. 

Depending upon the size of the project the project officer's job may become very 
complex and demanding. In general the project officer should be chosen based upon 
background and experience in the field. OMB Circular No. A-109 refers to the 
managers of major acquisitions as program managers. The A-109 program manager is 
not to be confused with the Coast Guard's program manager. A program manager in 
the Coast Guard refers to support or operating program managers who oversee the 
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various Coast Guard missions and support programs for those missions. A project 
officer in the Coast Guard acquisition process is the equivalent of the A- 109 program 
manager. 

Next, the acquisition paper (AP) is prepared. The acquisition paper is the key 
justification and documentation of a system as it progresses through the acquisition 
process. The acquisition paper contains, among other things, the acquisition strategy 
and estimated costs, a projected schedule and milestones, notable studies such as 
economic analysis and feasibility studies, and recommendations to proceed through the 
current Key Decision point. See Appendix A for the format of an AP. The Federal 
Acquisition Regulations require that an acquisition plan be prepared early in the 
acquisition process to promote full and open competition [Ref. 7: Sec. 1.7.103]. The 
acquisition paper satisfies the acquisition plan requirement. 

Key Decision 1, the authorization to proceed with the exploration of alternative 
system design concepts, occurs when the acquisition paper is approved for the first 
time by the Deputy Secretary. This is the nod to proceed with documenting the 
functional requirements of the proposed system. Input should be solicited from all 
possible beneficiaries of the system. 

Advancement to the competitive test and demonstration phase of the acquisition 
occurs upon the approval of the updated acquisition paper. Key Decision 2. The 
updated AP should contain updates on the system acquisition costs, updated goals and 
schedule, significant changes and status reports on program activities. In this phase, 
contractor proposed systems, based upon the functional and technical specification 
requirements, are evaluated on paper for economic comparison and technical 
compliance. An operational capabilities demonstration (OCD) is also required to 
demonstrate their compliance. • 

Upon completion of the test and demonstration phase the AP is once again 
updated. The test results and cost evaluations from this phase will be included in the 
AP update. Again status reports and other updates support the recommendation to 
proceed in the AP. Key Decision 3, commitment of a system to full scale development 
and limited production, occurs upon approval of the AP. Selection of the system that 
most economically and efficiently meets the needs and specifications happens during 
this phase. 

Key Decision 4, commitment of a system to full production, occurs upon the 
approval of the updated AP. At this point the selected system is procured and 
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distributed to field units as necessary to meet the documented needs of the operating 
agency. 

As the acquisition process progresses, quarterly reports must be submitted to the 
TSARC for review. The quarterly status reports shall assess cost, schedule and 
technical performance experience against predictions [Ref. 5: p. 9], and include 
observations and recommendations as to how the variance may affect the life cycle 
cost. Appendices E and F provide the sample format and status codes required for the 
quarterly status reports. 

C. SECRETARIAL REVIEW 

The secretarial review process applies to proposed systems that fall below the 
dollar requirements for major systems, but have: (1) total acquisition costs greater than 

520.000. 000; or (2) anticipated 3 year research and development costs that exceed 

50. 000. 000 [Ref 8: p. 1]. 

A one page memorandum similar to the memorandum for major systems 
candidates is submitted by 1 May of each year to the Assistant Secretary for Budget 
and Programs. This memorandum contains a brief recommendation and reasoning 
concerning the applicability of TSARC review and involvement in the acquisition. The 
Assistant Secretary for Budget and Programs prepares recommendations, based on 
input from other secretarial offices, and submits them to the Deputy Secretary. As 
soon as possible the Deputy Secretary makes a determination on each system and 
places them in one of the following categories: 

• MSA - Major Systems Acquisition 

• TPL - TSARC Program List 

• NBR - Normal Budget Review. 

A major systems designation of one of these lower cost acquisitions signifies the 
importance of or Secretarial interest in the particular project. The procedures discussed 
earlier for major systems acquisition must be followed. 

Systems included in the TSARC program list basically follow the same process as 
major systems. In fact it is a scaled version of the A- 109 process with the Key 
Decisions delegated to lower organizational levels. An acquisition paper must be 
submitted and approved by the Deputy Secretary, quarterly status reports are also 
required. However, the decision authority at the Key Decision points is delegated to 
the head of the responsible DOT agency, unless specifically withheld by the Deputy 
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Secretary upon approval of the AP. The Commandant is the Decision Authority for 
the Coast Guard. The Deputy Secretary should receive an updated acquisition paper 
for review and approval only if the acquisition exceeds any limitations imposed by him 
or if it deviates significantly from cost and/or schedule baselines. Under these 
conditions the Deputy Secretary's acquisition approval is necessary before the 
acquisition proceeds further. 

Programs not specifically categorized as MSA or TPL fall into the normal budget 
review category'. These systems will be considered in the budget review process for 
funding and approval. It should be noted that approval of an acquisition paper and 
designation of an acquisition as a major system or TSARC Program List does not 
guarantee funding in the budget process. The approved acquisition paper is used as 
background support information and justification of a project in the RCP submitted 
during the budget development process. 

D. PROCUREMENT AUTHORITY FOR ADP RESOURCES 

The General Services Administration (GSA) has exclusive procurement authority 
for the federal government for ADP resources under 40 USC 759 [Ref. 9: Sec. 
201-23.100]. Procurement authority may be delegated to agencies of the federal * 
government by GSA. Delegation of procurement authority (DPA) allows agencies to 
proceed with a particular ADP acquisition without further involvement from GSA. A 
blanket delegation of procurement authority has been granted to all agencies, which 
includes the Department of Transportation. For procurements made through 
competitive solicitation procedures 1 the following DPA is granted to executive 
agencies: 

• ADP equipment purchases not to exceed S2, 500,000 

• ADP equipment rental charaes including maintenance not to exceed S 1,000,000 
annually 

• Software acquisition not to exceed S 1,000,000 

• Maintenance services not to exceed SI, 000 ,000 annually. 

Agency DPA's can be further delegated to its organizational components. The 
Department of Transportation's delegation of procurement authority to the Coast 
Guard is S50,000 for ADP equipment which does not appear in the DOT ADP Plan, 
and a maximum of S300.000 for approved systems which appear in the DOT ADP Plan 



\ t ^ aiK * °P en com P et ition required by the Competition in Contracting 
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[Ref. 10: p. 9]. The DOT ADP Plan is a planning and budgeting document for ADP 
resources in the Department of Transportation. It was discussed in an earlier section 
of this thesis. 

Acquisitions of ADP resources by the Coast Guard which exceed its procurement 
authority delegated by the Department of Transportation must be presented to the 
Assistant Secretary for Administration (M-l) for approval. For ADP systems with 
acquisition costs which are expected to exceed DOT's blanket DPA, an agency 
procurement request (APR) must be submitted to the General Services Administration 
through the Department of Transportation. Coordination with GSA prior to 
submitting the APR is encouraged. Identification of problem areas early in the process 
may eliminate possible delays in approving the APR and the granting of the delegation 
of procurement authority for that particular acquisition [Ref. 9: Sec. 201-23.106]. DOT 
recommends use of the alternative APR submission, the description and format of 
which is shown in Appendix G. Two copies of the APR should be submitted to GSA. 
GSA will review the request and take action within 20 days of receipt of the necessary 
information. After 20 days, plus 5 days for mail delay, if no word has been received 
from GSA the agency may act as if the DPA has been granted and proceed with the 
acquisition process. The 20 day deadline is set by GSA when it responds in writing 
stating that the necessary information has been received. The commencement date of 
the 20 day review period will be in the notification. No solicitation or contracting 
activity may begin until the DPA has been granted. 

E. THE MODEL 

Now that some background has been provided for some of the most important 
mandated elements concerning acquisition of ADP resources, a model will be 
developed that incorporates everything up to this point. 

The Key Decision points discussed in the Major Systems Acquisition section 
remain the important milestones in any acquisition process which meet or exceed the 
criteria for secretarial review. However, for the purpose of an acquisition of off-the- 
shelf ADP resources, Key Decision 2 and 3 are usually combined into one decision 
[Ref. 6: p. 24] to streamline the process. It is sometimes referred to as customizing the 
acquisition. The proposed ADP acquisition model is based on redefining the phases 
between each Key Decision with a single broad term that describes the activities that 
occur during that phase. Figure 4. 1 illustrates the basic model. 
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Figure 4.1 Comparison of the Proposed Model with the A-109 Process. 



Each phase in the life cycle should be concrete and identifiable. Separation 
milestones between phases are major decision points. Transition is accomplished by 
satisfactory completion of predetermined milestones. This does not mean that 
requirements and determinations from an earlier phase cannot be reconsidered and 
possibly modified later. Problems are cheaper and easier to work out in the earlier 
phases than in the later ones. For example, requirements considerations should be 
handled early in the process while the analysis oriented personnel are working on the 
project. A contracting officer should not be left to make determinations on the 
functionality of hardware merely because a portion of the requirements analysis was 
overlooked. On the other hand, deleting an unnecessary requirement or adding a new 
critical function should not be ignored simply because that stage of the project has 
passed. A system that is obsolete or useless when it is finally acquired has failed 
somewhere along the acquisition process. 

It is very important not to proceed ahead in the project cycle before the 
authorization to proceed has been granted. This avoids wasted time, effort and money. 
All the necessary details possible should be considered and planned before proceeding. 

Documentation is also necessary. It may be used to prove regulatory 
compliance. More importantly, the thought process and reasoning which drove the 
project may prove invaluable at a later point in time. 

1. The Planning Phase 

The planning phase of this acquisition model begins with the conception of an 
idea to develop or acquire an ADP system. For the • purposes of this thesis, 
consideration will be limited to multipurpose hardware and software. The development 
or replacement of an ADP system may be considered for many reasons. Among the 
possibilities; obsolescence of an existing system, new requirements mandated by 
mission or law, new technological opportunity, or simply, a suggestion to improve 
performance and capabilities in any of the many things the Coast Guard does. 
Regardless of the origination of the idea, all systems must proceed through the same 
planning steps to be able to proceed on to the approval phase. 

First a preliminary analysis or feasibility study should be performed. The 
feasibility study looks into the technical, economic, operational and political 
implications and restrictions associated with the proposed system. After considering 
these factors, the formal objectives and a sense of the scope of the project are known. 
If the proposed system is technically, economically, operationally and politically 
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feasible, a decision can be made to proceed with the system planning based upon a 
preliminary cost benefit analysis done by comparing the objectives against against a 
rough cost from the feasibility study. 

The ADP Plan, as mentioned earlier, is a planning tool used by the Coast 
Guard and the Department of Transportation to budget for ADP equipment and 
services over a 5 year time frame. Submission to the ADP Plan should occur as soon 
as possible once a determination is made that the proposed system merits further 
consideration and could possibly be acquired. 

Defining system's requirements follows the feasibility study. When the scope 
of the project is understood, the determination of need and requirements analysis 
addresses considerations such as the type of information to be processed, security and 
privacy concerns, volume of data, probable benefits, site preparation and risks 
[Ref. 9: Sec. 201-30.007], See Appendix H for minimum requirements analysis 
considerations. 

For existing systems, conversion costs must be considered to insure that ADP 
needs are met at the lowest overall cost. Conversion costs include software conversion, 
site preparation and modifications, and travel and training expenses [Ref. 9: Sec. 
201-30.012-2]. As a rule they are expenses that would not normally be incurred 
without transition to a different system. Comprehensive software conversion studies 
are required in the following instances: 

• The estimated purchase price or life cycle cost of the svstem is expected to 
exceed S2.5 million; or 

• The cost of the conversion is to be used as primary justification for a 
compatibility limited requirement. 

If it becomes necessary or desirable to add to or replace a system with equipment 
which must be compatible with the existing system, a statement justifying the 
compatibility limited requirement must be prepared. The justification must include 
[Ref. 9: Sec. 201-30.009-3]: 

• Software conversion study 

• Mission essential data processing requirements 

• Analysis which shows the proposed method is lowest overall cost over the 
system life. 

Appendix I contains the considerations for determining whether a compatibility limited 
requirement is justified. 
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Completion of the various studies described above brings the planning phase 
to a close. The studies are prerequisites and necessary enclosures for documents to be 
submitted during the approval phase. 

2. The Approval Phase 

All the planning in the world can be done for a project, but that project will 
never progress until those in the position of approval grant their authorization to 
proceed with the project. Three major objectives make up the approval phase. 

First, advance approval must be sought through the ADP Plan. From the 
reported information, an obligation ceiling for ADP is passed down from OMB 
through DOT, eventually down to the level seeking authorization for its project. 
Project approval for the ADP Plan should be requested one year prior to its desired 
approval. The approval request is then published in the ADP Plan. 

The second major objective is to gain approval of the mission need statement, 
and if one is required, the initial acquisition paper. These two documents taken 
together, provide a formal statement of the project, an analysis of the costs and 
benefits, scheduled milestones, and other project management considerations. Refer to 
Appendices A and C for the contents of the acquisition paper and mission needs 
statement, respectively. The actual approval process for the MNS and AP is covered 
in Section B of this chapter. Major Systems. 

Finally, procurement authority for ADP equipment and services rests, by law, 
with the General Services Administration. Blanket procurement authority is delegated 
to agencies, not to exceed specified dollar thresholds. In cases where the projected 
costs will exceed the delegated procurement authority, an agency procurement request 
must be submitted to GSA through the Coast Guard chain of command and then 
through DOT. DOT review is contingent upon the project's appearance in the ADP 
Plan. GSA requires the MNS, a conversion study and, if appropriate, a determination 
of compatibility requirement. GSA approval of the APR results in the granting of a 
delegation of procurement authority. The DPA may contain restrictions and/or 
specific reporting requirements which apply to the particular acquisition. Section D of 
this chapter, Procurement Authority for ADP Resources, describes the agency 
procurement request process in more detail. 

Completion of the approval phase corresponds to Key Decision 1 of DOT's 
implementation of the A- 109 process. Key Decision 1 is the authorization to proceed 
with the exploration of alternative system design concepts. Key Decision 1 actually 
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occurs earlier in the acquisition process than the completion of the approval phase. 
Approval of the initial acquisition paper is Key Decision 1. The approval phase goes 
one step further by obtaining approval of the agency procurement request, which 
contains the approved mission need statement and other pertinent information from 
the initial acquisition paper. 

3. The Solicitation Phase 

The purpose of the solicitation phase is to prepare a request for proposal 
(RFP) to be made available for all parties interested in bidding on the proposed system 
or service. The conclusion of this phase occurs when the deadline for bids passes and 
the evaluation of proposals commences. 

A selection plan (SP) is prepared by the contracting officer in coordination 
with the program office responsible for the project. Appendix J contains the details of 
a selection plan. Approval of the selection plan is required prior to issuing the RFP. 

The Source Selection Official (SSO) approves the SP. In the case of large 
contracts, greater than S2 million, the Assistant Secretary for Administration is the 
SSO, unless he/ she chooses to delegate the authority. Submission of the selection plan 
to the SSO should be withheld until an acquisition paper has been approved if the 
procurement falls under the review of DOT Order 4200. 9A\ Acquisition Review and 
Approval, or DOT Order 4200. 14B, Major Systems Acquisition Review and Approval 
[Ref. 11: p. 

Members of the Source Evaluation Board (SEB) are specifically designated in 
the approved selection plan. Source Evaluation Board duties take priority over normal 
duty assignments [Ref. 11: p. 1 1 1-3]. The SEB is made up of a maximum of 7 members. 
Evaluation teams are formed from the members of the SEB. Advisors and experts 
outside the membership of the SEB may be brought in to assist the teams. However, 
acquisition related information available to those personnel should be limited to that 
which is necessary for satisfactory completion of their tasks. Source Evaluation Board 
recommendations are submitted to the SSO to provide assistance in and a basis for the 
selection/award decisions made by the SSO. 

Work on the RFP may begin sometime before approval of the selection plan. 
The request for proposals is prepared by the contracting officer. A draft RFP may be 
released to industry for questions and comments. Questions and comments from 
potential bidders clarify ambiguities in the RFP. More responsive, higher quality bids 
result from this process. The final RFP is typically available for review by the Source 



32 



Evaluation Board at one of its early meetings. The SSO is briefed on the RFP after it 
is reviewed by the SEB. 

Development of a source list, and evaluation criteria must be completed before 
the RFP can be considered for release. The source list contains recommended sources, 
but does not implicitly exclude any source not on the list. The evaluation criteria and 
weighted scoring procedures must be completed prior to issuing the RFP to insure 
impartial evaluations, and to let the bidders know what is considered important in their 
proposals. RFP information is contained in Appendix K. 

Proposed contract actions greater than S25,000 must be synopsized in the 
Commerce Business Daily (CBD) [Ref. 7: Part 1.5]. The notice must appear in the 
CBD at least 15 days before release of the RFP. This gives interested vendors, who do 
not appear on the source list, an opportunity to request a solicitation. At a 
predetermined date vendors, both on the source list or requesting solicitations, are sent 
a copy of the RFP. Deadlines for bid/proposal submissions are set. The deadline may 
not be less than 30 days from the release of the solicitation. 

4. The Evaluation Phase 

The evaluation phase begins after the solicitation deadline has expired and 
proposals have been received. Proposals arriving after the announced deadline are 
typically not evaluated. The SEB is convened to evaluate the proposals. First, a 
preliminary review is made of the proposals. Specifically, the SEB looks for proposals 
that may be eliminated at this early stage, before detailed analysis is performed. 
Proposals that are deficient in one or more areas or show that the offerer did not 
understand the solicitation are eliminated. Eliminated offerers are notified as soon as 
possible concerning the reasons for elimination, and to inform them that resubmission 
of their proposals will not be considered. 

Next, the evaluation team begins analysis of the proposals. Ambiguities in 
any proposal are directed back to the SEB. The SEB forwards them to the contracting 
officer, who contacts the offerer for clarification. After ambiguities are worked out, the 
teams evaluate the proposals based on the approved evaluation plan and weighting 
criteria. 

To evaluate the operation and performance of proposed systems, the use of 
operational capability demonstrations (OCD) and performance validation techniques, 
such as benchmarking, are required in contracting for ADP equipment systems, 
components and software [Ref. 9: Sec. 201-24.215]. The usefulness of the OCD 
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depends on the quality and completeness of the systems requirements in the RFP. One 
of the teams from the SEB will observe and score the OCD's. After evaluations are 
complete, each team provides a written report to the SEB describing the strengths and 
weaknesses of the various proposals. 

A preliminary determination of competitive range is made by the SEB. This 
determination eliminates all proposals that do not have a reasonable chance of being 
selected for final award. Those offerers eliminated at this point are promptly notified 
of the reasons for their elimination and that resubmission of their proposals will not be 
considered. 

Offerers who remain are given the opportunity to improve their proposals. 
Weaknesses and/or deficiencies are pointed out to them. No recommendations are 
made concerning how to improve or correct the proposals. Major rewrites of 
submitted proposals are not allowed at this stage and should not be considered. 
Revised proposals are rescored by the teams. Final scores from this stage are 
presented to the SSO in a written report. 

Completion of the evaluation phase corresponds to Key Decision 3. Recall 
that Key Decisions 2 and 3 are typically combined for acquisition of off-the-shelf ADP 
resources. Referring back to Figure 4.1, Key Decision 3 marks the end of Evaluation 
of Alternative System Design Concepts, and Test and Demonstration phases of the 
DOT A- 109 implementation. At this point the acquisition paper should be completely 
updated for review by the approval authority to proceed into the next phase. 

5. The Selection Phase 

Based upon the Source Evaluation Board's report, the SSO returns a 
determination to the SEB of contractors within the competitive range for contract 
negotiation. This is the beginning of the selection phase. 

Prior to negotiations with contractors the SEB advises the negotiating team of 
factors it considers important. The SEB also reviews the negotiating team's position 
and objectives before commencement of negotiations. 

All offerers are permitted adequate time to alter their proposals based on 
topics discussed in negotiations. Best and final proposals should be submitted by the 
date specified. The SEB reevaluates the best and finals but does not necessarily have 
to completely rescore them. The board prepares a written report to the Source 
Selection Official. The SSO then selects the offerer who will be awarded the contract 
and documents his her decision. 
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The selection phase is not complete until the unsuccessful bidders have been 
debriefed concerning their elimination from consideration. The contracting officer 
along with members of the Source Evaluation Board discuss the strengths and 
weaknesses of their proposals, individually. No comparisons are made. Only 
information pertaining to the particular proposal is discussed. Debriefing is done to 
acknowledge the efforts made by bidders. More importantly, it is used in hopes of 
receiving higher quality bids for future acquisitions. 

Completing the selection phase corresponds to Key Decision 4, Commitment 
of a system to full production. Although full production may not be an appropriate 
term for off-the-shelf ADP equipment and services, commitment to a system very 
accurately describes the Key Decision. 

6. The Implementation Phase 

The implementation phase commences at the conclusion of the selection 
phase. This phase covers the activities associated with establishing the ADP capability 
within the Coast Guard. Justification of the individual need for resources should be 
submitted by the requesting activity to the appropriate approval authority. For 
example, for Coast Guard wide applications the approval authority would be the 
responsible program manager. Funding sources should also be included with the 
justification. Hardware configurations and software requirements should be approved 
in coordination with a central technical office to insure system feasibility and 
compatibility with Coast Guard standards. 

7. Iterative System Evaluation Cycle 

A periodic system evaluation is one of the most important life cycle events, yet 
it is easily forgotten once the effort of acquiring a system is finished and the excitement 
has faded. The people involved with the acquisition typically go away and leave the 
system to the users. 

Several publications address the need for this evaluation. The Federal 
Information Resources Management Regulations call it an audit of installed systems; 
DOT Order 1370.9 refers to it as a post-installation audit; and the Department of 
Defense has a cyclic life cycle phase for ADP systems, called a systems effectiveness 
review. 

A thorough review of anv svstem is needed after it has achieved operational 
status. The primarv objective' is to determine if the svstem has achieved the cost 
and benefit goals which formed the basis for the decision to proceed with the 
system. Where their goals were not met, a new decision is required — on the 
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basis of the achieved benefits and the continuing cost to operate and maintain 
the system — as to whether the effort should be continued of abandoned. The 
post-installation audit also provides an excellent method of evaluating and 
improving the planning and development process. Post-installation audits must 
be ^plapned^to check accuracy, quality, and completeness of the system. 

The life cycle of an ADP system begins when planning is started and 
continues until disposal of the system. Studies, evaluations and other documentation 
are required during the acquisition portion of the life cycle. The historically and 
hopefully longest life cycle phase is the deployment and operation phase. An 
adequately planned system should satisfy its requirements for a sufficiently long period 
of time to justify itself and then some. It does not make sense to quit managing and 
documenting a system after the acquisition has been completed. The majority of the 
system's life cycle remains after the acquisition is finished. . 

The iterative system evaluation cycle at the end of one system's life cycle may 
coincide with the planning phase for the system that will eventually replace it. 
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V. THE ORIGINAL STANDARD TERMINAL ACQUISITION 



A. THE ACQUISITION 

The Coast Guard Standard Terminal is an acquisition that has affected the Coast 
Guard in virtually every activity and mission it performs. Standard terminal systems 
maintain pay data (JUMPS), marine safety information (MSIS) and many other 
applications including unique programs written by local programmers for a particular 
unit. Standard terminals are found everywhere in the Coast Guard, from headquarters 
offices, to ' research and development facilities, to ships on patrol. This chapter 
contains a brief acquisition history of the Coast Guard Standard Terminal. The 
process used to acquire this resource will be presented using the acquisition model 
described in the previous chapter. 

1. The Planning Phase 

Development of several major applications was under consideration during the 
late 1970's. Requirements for the standard terminal were based on the requirements 
for those applications. As the planning progressed the requirements matured. What 
originally started out as a dumb terminal grew into a powerful microcomputer with 
telecommunications features and the capability to be configured in a cluster." 
Commandant Note 5233, dated II June 1979, solicited input from the Coast Guard to 
help determine what capabilities were necessary and desireable. The request for input 
from the whole Coast Guard got everyone involved in the requirements analysis. 
However, it seems the requirements for the system had pretty much already been 
determined by the major applications needs. The Commandant Note asked for input 
on such things as keyboard layout and other terminal features which would not 
severely impact the proposed system as it stood at that time. The survey gathered 
input on the degree to which the proposed standard terminal characteristics were 
desired and/or necessary. 

Soon after the Coast Guard decided to proceed with the acquisition of a 
standard terminal, lead members of the project began selling the concept and benefits 
to high level Coast Guard and Department of Transportation officials. Because this 
was the first attempt at a major standardization project which would also put high 
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computer capabilities at all levels of the Coast Guard, the project was viewed as more 
political than anything else. High level briefings were used to get the support of those 
who could do the most to keep the momentum of the project going. They were also 
used to help prevent the shift of inertia against the project. In addition to the 
applications envisioned at that time, the standard terminal was presented as a 
capability that would be used by the Coast Guard in more ways than could be 
conceived of then. Because of the relatively new technology concerned, many project 
managers had difficulty grasping the potential benefits it would provide to their 
programs. Budgets and specific requirements were avoided until the concept was sold. 
Later, technology reports in computer publications such as BYTE and ACM would 
help provide the acquisition team with some of the required and optional features in 
the standard terminal specifications. 

The standard terminal concept was submitted to the Coast Guard ADP Plan. 
A description of the applications to be satisfied and the Coast Guard ADP 
requirements, both current and future, were identified as goals to be achieved by 
implementation of the standard terminal. 

The Coast Guard established a policy to place ADP costs with the people 
using the capability. Users pay for what they need and use. Consequently, no 
standard terminal RCP was approved to pay for the whole project. Rather, individual 
program managers were left to determine the standard terminal requirements for their 
programs and submit' budget requests for those needs. 

2. The Approval Phase 

Because the estimated cost of the acquisition exceeded the Coast Guard's and 
DOT'S blanket procurement authority, an agency procurement request was submitted 
to GSA. The APR submitted on 20 August 1979 estimated the terminal acquisition 
costs at approximately S6 million over a 5 year contract life. Review by the General 
Services Administration took about 3 months. The delegation of procurement 
authority was granted by the Assistant Commissioner for Agency Services and 
Procurement in a letter dated 14 November 1979. 

The standard terminal appeared in the first Coast Guard ADP Plan 
promulgated on 11 June 1979. Although no specific mention of approval is found in 
the first ADP Plan, conceptual approval must have been granted by this point in time 
by the Coast Guard and the Department of Transportation because the project 
continued. 
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Figure 5.1 depicts the activities which occured during the planning and 
approval phases of the standard terminal acquisition. 

By April 1980 the acquisition had gained two of the three approval objectives 
mentioned in the model; the delegation of procurement authority had been granted, 
and the ADP Plan submission was approved. The third objective in the model is 
approval of the acquisition paper. Research through the remains of the acquisition file 
turned up no sign of an acquisition plan. Acquisition schedule goals and milestones 
appear on several documents. However, the fact that no acquisition plan exists (or can 
be found) severely impairs the depth of review possible. Referring back to the 
secretarial review’ process, this acquisition's original estimated cost of S6 million did not 
meet any of the criteria for secretarial review’. Therefore, no acquisition paper w r as 
required. The acquisition team realized the A- 109 process w r ould apply to the standard 
terminal both in concept and cost. Cost estimates were deliberately kept low to keep 
the project from being administratively delayed in the A- 109 process. 3 

Having gained w’hat approval was necessary the acquisition process moved 
into the solicitation phase. 

3. The Solicitation Phase 

According to my model the solicitation phase begins upon the approval of the 
selection plan. A memorandum from the Coast Guard Commandant to the Secretary 
of Transportation, via the Deputy Secretary, was approved as the selection plan. The 
selection plan, dated 7 February 1980, contained recommendations, an acquisition 
schedule and nominations for the Source Evaluation Board members. Two documents 
followed w’hich completed the selection plan. "Source Evaluation Board Procedures for 
Evaluating Proposals" was distributed on 16 June 1980. And, a letter assigning the 
SEB evaluation teams was signed on 14 July 1980. 

As I mentioned in the model, work on the request for proposal may begin 
prior to the approval of the selection plan. That is exactly what occurred in this 
acquisition. A draft RFP was sent out to industry for comments of 5 December 1979, 
five months before the selection plan was w'ritten. The final RFP was released to 
bidders on 7 June 1980. Solicitation phase activities are show’n in Figure 5.2. 



3 E.M. Fiegel, "Trip Report of 2 Julv 1986". summarv of an interview with Dr. 
Jo|eph Dicenza,“ project officer for the original standard terminal acquisition, 3 July 
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Figure 5.1 Standard Terminal Planning and Approval Phases. 
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Figure 5.2 Standard Terminal Solicitation Phase. 
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4. The Evaluation Phase 

The evaluation phase began after the deadline for proposals had passed. A 
total of seven proposals were received by the closing date, 2 December 1980. 
Evaluations by the SEB teams commenced soon after that. Operational capability 
demonstrations began on 9 March 1981 and continued through 30 March 1981. 
Contractors were each scheduled for a 2 day demonstration. 

Efforts of the Source Evaluation Board teams were delayed by job 
responsiblities of the team members. 4 Interruptions and delays in SEB team meetings 
at headquarters had an adverse impact on the effectiveness of the SEB teams. 

More serious problems were to come. The final months before contract award 
brought a major turnover in project personnel. Military transfers and a retirement 
removed the acquisition leaders from the project and left less experienced people to 
take their places. Although the majority of the acquisition milestones had been 
achieved, it is obvious that the turnover affected the initial distribution and 
management of the standard terminal. 

5 . The Selection Phase 

Preliminary reports from the SEB on the evaluations were made to the SSO. 
On 23 March 19S1, the SSO approved "an optional approach to competitive range". 
Although the document explaining this approach was not found in the acquisition file, 
it appears to be the SSO's determination of contractors within the competitive range 
for contract negotiations. With the determination of competitive range the selection 
phase began. 

For various reasons, technical noncompliance, failure of the OCD, or late 
submission of their proposal, the number of bidders going into contract negotiations 
was reduced to two. 14 May 1981 was the deadline for best-and-final offers for this 
contract. Final Source Evaluation Board review was completed on 8 June 1981, and 
the contract for hardware, software and support sendees was awarded to C3, 
Incorporated on 29 June 1981 for services estimated at S45.4 million. It was a firm 
fixed price requirements contract with options to renew annually. Procurements from 
the contract to be allowed for a maximum of 60 months and maintenance support 
sendees for up to 120 months. Contract award came more than a year later than the 
acquisition schedule in the 7 February 19S0 selection plan, and at more than seven 



. 4 Telephone interview with LCDR Tim Fowler, Coast Guard Headquarters, 19 
June 1986. M 
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times the cost estimated in the agency procurement request. Significant activities in 
the evaluation and selection phases are shown in Figure 5.3. 

6. The Implementation Phase 

After contract award, some hardware and software were distributed to various 
sites by program managers. Application software was slow to be distributed due to 
development delays. Development software available to users was utilized in producing 
various local applications. However, in some cases the hardware w r ent untouched 
because the sites were not adequately prepared to use it. The standardization discussed 
in the C3/IRM Plan has been slow in becoming a reality. 

Realizing that better acquisition justification was necessary, a Commandant 
Instruction addressing the issue was distributed to the Coast Guard (Ref. 13]. The 
instruction requires justification documentation to be submitted with the procurement 
requests for any ADP acquisition from any source for less than S50,000, or for any 
ADP acquisition procured from the standard terminal contract. Copies of the 
justification documentation must be kept in a system acquisition file. Systems 
procured prior to the date of the Commandant Instruction were required to work up 
adequate documentation to place in their acquisition file, although no approval was 
required. This justification process of existing systems identified under-utilized and 
unused equipment for redistribution to sites with documented needs. 

7. The Iterative System Evaluation Phase 

User support w r as lacking after the contract was awarded. No formal 
communications existed among Coast Guard users. Furthermore, there was no 
effective liaison between the Coast Guard and the vendor for user support. 

The Systems Management and Engineering Facility (SMEF) at Station 
Alexandria, Virginia was tasked with the configuration management duties for the 
standard terminal. SMEF also provides the liaison between the Coast Guard and C3 
Incorporated. Also, the information center concept was introduced to establish formal 
communications channels within the Coast Guard. Information centers are set up at 
each Coast Guard District office and Headquarters as a central contact point in their 
respective areas. Information centers are used by users seeking assistance. They also 
disseminate Coast Guard ADP policy to the standard terminal users. 

Otherwise, the iterative system evaluation phase has consisted mainly of 
studies necessary to eventually replace the existing standard terminal systems and their 
support. 



43 




Figure 5.3 Standard Terminal Evaluation and Selection Phases. 



44 




• April 1985 - Feasibility Study 5 

• August 1985 - Procurement Plan 6 

• February 1986 - Software Conversion Study 7 

• April 1986 - Functional Requirements 8 

• May 1986 - Acquisition Support Plan (draft) 9 

• May 1986 - Comparative Cost Analysis 10 

System evaluations can occur at many levels. Considering the standard 
terminal as a Coast Guard system, a system review would evaluate how the standard 
terminal meets the needs of the Coast Guard. System reviews of major applications 
should also be done to determine how effectively the standard terminal is fulfilling the 
requirements of the application. Finally, a system review can be performed for a single 
site, like a group office or ship. Reviews of this sort would determine the adequacy of 
the resource in an office or stand alone environment. 

Although some systems have been evaluated, 11 it does not appear that a 
periodic post-installation audit occurs on a formal basis for most systems. However, 
brief site evaluations are done because users must justify acquisition and expansion of 
their systems procured under the standard terminal requirements contract. 

B. CONTRACT EXECUTION 

Funding for procurement of equipment and services from the standard terminal 
contract has come from the various operating and support prograriis. After the 
acquisition process was completed, RCP's submitted by program managers have 



5 Feasibility Study, Standard Terminal Re-Competition, U.S. Coast Guard, Office 
of Command, Control, and Communications, April 1985. 

6 Standard Terminal Procurement Plan, U.S. Coast Guard, Office of Command, 
Control, and Communications, August 1986. 

7 Standard Terminal Software Conversion Study Final Report, Wilson Hill 
Associates, Inc., Washington, DC, 18 February 1986. 

o 

5 Functional Requirements for the U.S. Coast Guard Standard Terminal. Federal 
Computer Performance, Evaluation and Simulation Center, Alexandria, VA, April 



9 Standard Terminal Acquisition and Support Plan (ASP) Review Board Meeting, 29 
May 86, U.S. Coast Guard, Commandant (G-Tt) Memorandum 10550, 9 May 1986 . 

10 U.S. Coast Guard Standard Terminal Replacement Cost Analysis, Comparative 
Cost Analysis. American Management Systems, Arlington, VA, 27 May 1986. 

11 The 13th Coast Guard District has conducted at least two, district wide studies. 
Thirteenth District United States Coast Guard Standard Terminal Survey. 29 June 1984. 
and Thirteenth District United States Coast Guard Computer Users Survey 1985, 23 
October 1985. 
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included funds for procurement of standard terminals. The Coast Guard uses this 
rationale to justify the claim that this project, with an estimate of S45.4 million at 
contract award, did not fall under secretarial review. Procurement was broken up into 
smaller purchases by the many programs. The Coast Guard reasons that they merely 
provided the technical expertise in acquiring the ADP capability for the programs to 
use as necessary. Therefore, it was in fact many smaller systems that were procured 
rather than one large Coast Guard system. Both sides could present valid arguments, 
however, this rationale was used successfully to complete the acquisition and secure 
funding for the standard terminal. 

The standard terminal contract has been renewed annually over the past 5 years. 
Because of the changing Coast Guard requirements and technology’ improvements, the 
contract has been modified many times, 35 modifications by 20 November 1985. 
Modifications have added and deleted equipment and services from the contract. Price 
adjustments have also occured as a result of negotiations with C3, Incorporated. A 
significant modification was issued on 30 October 1985. The maximum order limit on 
hardware items (terminals, storage devices, printers) was increased to correspond with 
the maximum limits allowed in the delegation of procurement authority from GSA. 

By 1 July 1986 an estimated S66.6 million had been spent on procurements from 
the standard terminal contract. Because standard terminal equipment was not accepted 
until September 1982, the 5 year procurement contract with C3, Incorporated is not 
expected to expire until September 1987. 
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VI. CONCLUSIONS AND RECOMMENDATIONS 



In the first chapter I outlined the purpose for conducting the research into this 
particular subject, to provide lessons learned from the original standard terminal 
acquisition. I have avoided in-depth contracting issues because of my limited 
knowledge and experience in that field. 

Several studies have been conducted which have resulted in recommendations to 
improve the acquisition process and to provide more effective management of standard 
terminal systems. Others have written their own lessons learned letters and documents 
which have pointed out shortcomings in the management and acquisition process. 
Those studies are listed among other reference material in the bibliography. It seemed 
inappropriate and redundant to restate recommendations and conclusions presented in 
other studies. Rather. I chose to limit my findings to significant management and 
acquisition issues which, in niv opinion, have not been adequately documented or 
considered. 

A. SYSTEMS MANAGEMENT ENGINEERING FACILITY 

Conclusion: SMEF provides significant management functions and user support that was 
previously nonexistent or inadequate. 

After the acquisition of the Coast Guard Standard Terminal was completed, the 
system was not effectively managed with regard to user support. Convergent 
Technologies and C3, Incorporated were sw'amped with calls from users. Calls ranged 
from inexperience problems from new users to software and hardware enhancement 
suggestions. There was virtually no control over direct communication with the 
equipment supplier. Realizing that a more controlled, effective approach was necessary' 
the Coast Guard appointed a Systems Management and Engineering Facility, currently 
at Coast Guard Station Alexandria, Virginia, as the direct liaison for the Coast Guard 
to the equipment manufacturers and suppliers. Support requests and complaints work 
their way up from the users to a central point at the cognizant Coast Guard district or 
Headquarters information center. Requests reaching this point are sorted out. Those 
requests that can be handled at this level go no further. Others that are beyond the 
scope of the information center are tunneled up to SMEF. SMEF advisors and 
specialists typically have the knowledge and experience to immediately assist with 
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support requests at their level. If not, they have the resources and authority to work 
out a solution on their own or in coordination with the equipment/ services suppliers 
and manufacturers. Centralized user support and support documentation provided by 
SMEF reduce the administrative burden on everyone involved in the process. It also 
saves time in the identification and solution of problems since they need only be solved 
once rather than many times. An electronic bulletin board has been established to 
provide easier communications with SMEF. 

SMEF also provides the same type of support with configuration management. 
The program managers, project officers, equipment suppliers, users and SMEF itself 
submit change proposals for hardware and software. Evaluation, approval or 
disapproval, documentation, change management and monitoring the status of changes 
are all configuration management functions of the Systems Management and 
Engineering Facility. 

The establishment of the SMEF was an extremely valuable move for the 
management of the Coast Guard Standard Terminal. SMEF evaluates, approves and 
distributes new software releases. It acts as the technical liaison for the Coast Guard 
in matters concerning the standard terminal. Configuration management is 
administered by the competent group of individuals that make up that organization. 
Without SMEF providing its support and guidance, the standard terminal concept 
would not have attained the level of use and acceptance that it has. 

B. FUNDING 

Conclusion: Because no funds were budgeted for the original standard terminal 

acquisition, phases of the acquisition were altered to take advantage of money when it was 
available. 

Throughout the acquisition process a constant concern is the cost of the system. 
Beginning in the planning phase, the feasibility study provides a gross cost estimate, 
possibly only the order of magnitude. Submissions to the ADP Plan provide the first 
budget figures to budget planners as the system gets closer to reality. The mission 
need statement, acquisition papers, and agency procurement request require proposed 
budget information before they are approved. Yet with all the requirements to develop 
budgets and spending plans the managers of an acquisition could possibly never have a 
budget commitment. Contract award may occur with no money budgeted for that 
contract. Given the current austere budget situation for the entire Government makes 



48 



this no less surprising. Why allow so much time, efTort and money to go into a project 
that may never be adequately funded? 

Program managers such as the Office of Command, Control and 
Communications have funds worked into their budgets to perform the studies and 
evaluations necessary to insure their programs provide an adequate level of support to 
their program constituents. Feasibility studies, requirements analysis, and conversion 
studies are among the acquisition process studies which are funded out of operating 
and contingency dollars worked into those budgets. 

Even though the acquisition studies get funded as the process progresses, there is 
not necessarily a commitment to fund the project. Resource change proposals (RCP) 
are submitted and may or may not be approved. The acquisition process could still 
continue after its RCP has been denied. The original standard terminal acquisition was 
paid for with money reprogrammed by various program managers. This caused phases 
of the project to be rushed to avoid funds from expiring at the end of a quarter or 
fiscal year. Equipment was also paid for out-of-hide or by using money budgeted for 
office equipment. 

To avoid repeating this scenario there should be milestones in' the acquisition 
process that correspond to milestones in the budget process. A project should not be 
allowed to continue without a budget commitment. At the time the initial acquisition 
paper is approved, the Department of Transportation should take on the commitment 
to fund the project, at least partially. 

Recommendation: Acquisition milestones should coincide with budget process milestones 
to insure adequate funding is available for contract execution. 

C. EVALUATION TEAMS 

Conclusion: Unnecessary interruptions and delays, due to other duties and job obligations, 
adversely affected the efforts of the SEB teams. 

Teams made up of members of the Source Evaluation Board and advisors 
evaluate offerers proposals. The selection plan, prepared by the contracting officer in 
coordination with the responsible program office, explicitly identifies each member of 
the Source Evaluation Board. Prior to including someone on the SEB, it should be 
determined whether or not that person will be able to devote the necessary time to the 
board. Members and their bosses should realize that Source Evaluation Board duties 
take priority over normal duty assignments. 
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Several of those interviewed mentioned problems and delays in getting their team 
members together at times during the original standard terminal acquisition. Team 
members attended team meetings at headquarters in Washington, DC. Most team 
members were stationed at headquarters. While this sounds convenient on first 
consideration, it sometimes hindered the efTorts of the teams. First of all, team 
members at headquarters often find it difficult to ignore normal duties. Their co- 
workers, both senior and subordinate, may also find it difficult to allow team members 
to devote full time and attention to the Source Evaluation Board. Distractions and 
delays were caused by this situation. 

Avoiding this situation would allow the Source Evaluation Board members to 
perform their duties at their own pace, undisturbed. Sending the SEB members on 
temporary' assigned duty (TAD) would provide them with the job isolation necessary. 
Temporary duty at a private meeting place could cost more money than available, plus 
it might be difficult to justify. Perhaps TAD to Station Alexandria Virginia would be 
the best solution. Members would be isolated from their jobs, unless team members 
were from Station Alexandria. Station Alexandria is convenient to headquarters, which 
would avoid costly travel and per diem expenses. Because Station Alexandria is a 
Coast Guard unit, team members would not lose the benefit of operational and 
administrative support. Communications facilities are also available. Finally, some of 
the most knowledgeable computer people in the Coast Guard are stationed at Station 
Alexandria. This could be advantageous if it becomes necessary to seek advice outside 
of the SEB evaluation team. 

Recommendation: Isolation of the SEB teams away from their jobs should be allowed 
during evaluation periods. 

D. EXPERIENCE AND TRAINING 

Conclusion: Project officers play the most important role in determining whether or not 
an acquisition project effectively achieves its intent within time and budget constraints. 

It is obvious that the Government is concerned that the big money which is 
spent on major systems should be managed effectively. A recent amendment to Title 
10, U.S.C. Section 85.1622, requires that program managers in Department of Defense 
major systems acquisitions have a minimum of eight years experience in related 
technical fields and acquisition [Ref. 14: p. 9]. Although the cost and scope of the 
intended DOD major systems far exceed that of the standard terminal, proper 
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management and control techniques will help projects achieve success within minimum 
cost and time regardless of the size. Experience, training and education are three 
factors that will benefit the program manager in fulfilling his/her responsibilities. 

At the time of the original standard terminal acquisition, its project officer had 
very little experience in the ADP field. He was a general line officer in the Coast 
Guard with a one week ADP course behind him. His acquisition experience with ADP 
was more extensive, however. He oversaw the network procurement resulting in the 
GTE Telenet service contract, and participated in a minicomputer acquisition for the 
Operations Computer Center at Governor's Island, NY. In fact, there were very few 
people fully qualified to manage a large integrated, microcomputer acquisition because 
a project of this scale with micros had never been done before. 

Now ADP experience is available in the Coast Guard. The Coast Guard should 
utilize its personnel where they can contribute the most to the service. Project officers 
should be selected on the basis of experience, education and willingness to perform the 
job, not merely to fill an open billet. 

Recommendation 1: Project officers should be selected based on experience , education, 
training and enthusiasm for the project. 

Recommendation 2: ADP oriented career paths should be formally developed to insure an 
adequate pool of officers is available with the necessary experience to manage the Coast 
Guard's C3URM programs. 

E. PROJECT PERSONNEL CONTINUITY 

Conclusion: The original standard terminal acquisition team was broken up during a 

critical time before the acquisition was complete. 

One of the most recurring comments made during interviews was the lack of 
continuity in the management of the original standard terminal acquisition. The 
project was driven by the enthusiasm and foresight of a few Coast Guard officers. 
Their job was monumental considering the scope of the project they undertook, not to 
mention the new technology concerned. The management team began breaking up 
because of military transfers and discharges shortly before the project was completed. 
Relatively inexperienced personnel were put into top positions to finish up. During the 
transition much of the documentation and expertise were lost. 

It seems like such a basic idea, to put a team in to work on a project and leave 
them there until the project is done. Although transition is inevitable in the military, 
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scheduling the transfer of personnel to avoid the critical stages of an acquisition would 
avoid unnecessary problems in an already complicated process. 

Except in cases where the project officer is carrying out his/her responsibilities 
unsatisfactorily, the project officer should see the project through to completion. If 
that is not possible, sufficient relief time should be allowed for the successor to benefit 
from the experiences and lessons of the predecessor. 

Recommendation: The acquisition team , especially the project officer , should remain with 
an acquisition until the project is finished. 

F. REGULATIONS 

Conclusion: Information concerning AD P acquisitions is difficult to gather because of the 
numerous sources , some of which are outdated. 

Research into the acquisition of ADP equipment and services was a very 
enlightening and frustrating experience. Regulations and requirements concerning the 
federal. Department of Transportation and Coast Guard acquisition processes are 
spread throughout numerous documents and publications. The majority of Federal 
acquisition information related to ADP is contained in the Federal Information 
Resources Management Regulations which is published by the General Services 
Administration. That publication is in a sense the bible to which all Government 
agencies must conform in ADP matters. The Department of Transportation has DOT 
Orders that are outdated, contradictory and confusing. The Coast Guard directives 
concerning ADP are no better. It does not seem unreasonable to expect the Coast 
Guard ADP Management Manual to be a useful source of information in a research 
projects such as this thesis. It was not. 

The Department of Transportation and the Coast Guard should undertake a 
comprehensive review of their publications. Benefits such as more up-to-date and 
comprehendable information would assist those personnel with the need for that 
information. After all, of what good is an outdated publication? 

The Department of Defense has more regulations for ADP acquisition than DOT 
and the Coast Guard combined. DOD does, however, have an ADP Supplement to 
the Federal Acquisition Regulations. Such a supplement to the Transportation 
Acquisition Regulations (TAR) would certainly help to eliminate any ambiguity or 
confusion on the requirements for ADP acquisition. The research for a TAR 
Supplement covering the acquisition of ADP resources need only be done once, rather 
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than repeating the drill each time an acquisition commences. A step-by-step 
acquisition process that can be tailored to individual projects should be developed and 
published. Regulations mandate the legal and proper process to acquire ADP 
resources. Having to search through volumes of regulations in various places increases 
the probability that something will be left out, ignored or forgotten. 

Recommendation: A single reference document for Department of Transportation ADP 
acquisitions should be developed and frequently updated. 

G. STANDARDIZATION AND COMPATIBILITY 

Conclusion: Nonstandard microcomputers can be procured with little consideration of the 
standard terminal requirements contract. 

Standardization is one of the most important concepts behind the acquisition of 
the Coast Guard Standard Terminal. A few foresighted Coast Guard officers saw the 
need for choosing a single type of hardware that would be able to support the various 
Coast Guard applications at that time and into the future. Microcomputers were just 
starting to come out and many organizations including the Coast Guard were 
scrambling to capitalize on their capabilities. Standardization back then has led the 
Coast Guard to its success with microcomputers today. 

The standard terminal contract is a requirements type contract. That means that 
any application which can be satisfied by the hardware, software and/or services in the 
contract, must use the contract as the source for its procurement. If adequate 
justification is provided to acquire ADP equipment, other than that on the contract, 
the Coast Guard typically grants approval. In some cases the justification provided 
should not warrant approval, although it sometimes does. While researching my topic, 
one headquarters office convincingly proved this point. The office managed a large 
minicomputer for approximately 100 users. Justification was approved and money 
provided for acquisition of a Coast Guard Standard Terminal for that office. The 
microcomputer was never really used and was soon given to another office that had a 
need for it. Later, justification from the same office that had recently given away a 
standard terminal, was approved for the purchase of an Apple Macintosh. 

Stringent justification criteria should be required before allowing acquisition of 
ADP equipment and services not appearing on the requirements contract. 
Proliferation of noncompatible micros was the original intent. Now that the Coast 
Guard has such a considerable investment in the Convergent Technologies micros, it 
should be doubly important that our computers remain compatible. 
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Recommendation: The Coast Guard should apply more stringent justification criteria 

before approving requests for noncompatible microcomputers. 

H. PERIODIC SYSTEM AUDITS 

Conclusion: Inadequate reviews are conducted on installed systems to insure they are 
effectively utilized and used for purposes for which they were justified. 

A key consideration, once an ADP system is acquired, is to periodically evaluate 
the system to insure its adequacy. It cannot be emphasized enough as to how 
important this iterative review cycle is. After implementation, the system should 
continue to perform its proposed functions satisfactorily. If not, redesign or 
reclassification of the system should occur. The goal of the acquisition process is to 
provide a system that satisfies the needs of the users at lowest overall cost to the 
government. A system not being used to its potential or so seriously incapable that it 
is not used, must be reevaluated. Periodic evaluations prevent a system from becoming 
either of the two extreme examples mentioned. 

Performing a periodic system review is typically not done on Coast Guard 
systems, even though it is recommended and desireable. System growth, for the most 
part, has been determined by a select few knowledgeable users or system managers who 
.have an idea of what they want the system to do. Use and acceptability, however, is 

determined solely by the system users. Therefore, periodic, formal reviews should be 

# 

scheduled and performed to insure ADP systems are effectively and efficiently meeting 
the needs of users, managers and the Coast Guard as a whole. This program should be 
the responsibility of the program manager sponsoring the ADP system. Results should 
be reportable to the Command, Control and Communications support manager (G-T). 
Considering the rapid rate of change in ADP technology, the frustratingly slow 
acquisition process and the continuing evolution of Coast Guard missions, a biennial 
review cycle would suffice on a trial basis until a review provides a basis for a better 
audit interval. 

Recommendation: Periodic system reviews should be done at every ADP site and Jo r each 
of the major applications to insure proper resource utilization and cost effectiveness. 

I. ACQUISITION DOCUMENTATION 

Conclusion: Inadequate documentation exists j'rom the original standard terminal 

acquisition. 
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Documentation in the acquisition file for an ADP system should include studies, 
correspondence and just about anything else that concerns the particular system. One 
source, more than any other, documents the life cycle of a system, the acquisition 
paper. It has been the practice of the Coast Guard to decide on its own whether or 
not an acquisition paper is submitted for proposed ADP systems. Avoiding 
unnecessary levels of bureaucracy is a valid concern in these days of acquisition delays 
due to the many levels of approval necessary. The acquisition paper approval process 
may be waived if it is convincingly proven that the system does not come under the 
secretarial review process for major systems acquisition (MSA) or TSARC program list 
(TPL). This decision, however, is to made by the Deputy Secretary not by the Coast 
Guard. The Coast Guard can only provide an convincing argument. 

An acquisition paper should still be developed, even if it is not required. In most 
cases the same general procedures should be followed for smaller systems as larger 
ones. The acquisition paper format is designed to contain most of the necessary 
information on the system's acquisition. Changes in the project are reflected so that 
the acquisition paper always reflects the current state of the acquisition as well as an 
accurate account of what has occured to that point in time. Preparing an acquisition 
paper should not be considered just another bureaucratic exercise. Rather, it should be 
realized as the systems planning and documentation tool that it is intended to be. Had 
an acquisition paper been done for the original standard terminal acquisition, 
subsequent ADP acquisition projects throughout the Government could have tailored 
and fine tuned their microcomputer acquisition projects from it. The biggest benefit of 
all would have been to the Coast Guard at this point in time w r hen replacement 
systems are under consideration. 

Recommendation: To insure systems planning and documentation are satisfactorally done, 
an acquisition paper should be developed and maintained for future acquisitions. 

J. DEVELOPMENT TOOLS AND APPLICATIONS 

Conclusion: Poor initial planning for applications software has left Coast Guard users 
with hardware and software tools that they do not know how to effectively use. 

After five years of the standard terminal the Coast Guard should strive to 
accomplish one of its primary objectives of the C3/IRM architecture. Data should be 
shared and accessed more readily. Program managers should determine what data and 
applications are necessary for their constituency. Specifications for the applications 
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could be gathered from users in the field who have developed their own systems. The 
benefits of lessons learned from many development efforts reduce the probability of 
encountering the same problems. 

The standard terminal was intended to be a tool for users to access and utilize 
Coast Guard data. Development software is provided at no extra cost when hardware 
is delivered to sites. Many users and some system managers are overwhelmed by the 
number of software and hardware tools available to them that they do not know how 
to use. Others are off and running with whatever is available to them. Instead of 
putting their systems to use in ways intended by the C3/IRM architecture, ambitious 
users spend time attempting to automate unnecessary and trivial tasks, or trying to 
learn how to use what is provided to them. 

The Coast Guard is not in the business of training programmers and systems 
developers. Rather the Coast Guard is attempting to utilize the C3 architecture to its 
fullest potential to achieve predetermined goals. Yet the delays in getting standard 
applications software into the field have forced users to innovate in order to make use 
of the standard terminal. Consequently, programs developed by local innovators 
typically are poorly planned, inadequately documented and virtually unmaintainable. 
The heirs to these applications are in a difficult position. They do not know how the 
programs work or if the results they provide are accurate. In most cases the costs 
exceed the benefits associated with this type of development approach. Instead of 
being a useful tool, the standard terminal has occasionally been a time and effort sink. 
A Coast Guard report points out that several mid-level managers have adversely 
affected their careers by becoming too involved in attempting to automate too many 
things [Ref. 15: p. 4], These cases could refer to the very same innovation encouraged 
and applauded by failed planners. 

The C3/IRM architecture emphasizes standard software. More effort and 
planning should go into accomplishing that. Adequately planned and successfully 
implemented applications will develop user confidence and better acceptance of the 
standard terminal. Data integrity and usefulness will improve if unnecessary data 
conversions are eliminated. Applications will benefit from standardization and a wide 
user base involved with using and improving the system. 

Users and developers are two different groups. The standard terminal is targeted 
for the Coast Guard users. If the Coast Guard continues to rely on internal 
innovation, it should realize that those innovative efforts in programming and 
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implementation are using manpower, time and dollar resources that are most likely 
being diverted from other necessary missions. Probably every unit has had at least one 
experience with struggling to develop a unique application or attempting to implement 
another unit's development. Such efforts are obviously occuring at the wrong level of 
the Coast Guard where inadequate resources are available. It may seem like heresy to 
suggest that development tools be withheld from Coast Guard users, but that may be 
necessary. Creativity and innovation will not be suppressed, we should realize that 
those innovators are still going to be out there. 

Software should be made available only after justification has been approved, 
similar to the hardware justification. Some cost savings may be realized by reducing 
software licensing and distribution. Iterative system reviews could be used to 
determine what software is or is not necessary for various sites. Certainly much disk 
space and time will be saved if several of those personnel attempting to learn Pascal or 
Cobol will be forced to do it at the appropriate time and in the proper environment. 
The proper environment could be at home on their own computer or in school or 
training classes, but not at work on Coast Guard resources which were not intended 
for that use. 

The Coast Guard program managers should develop support applications. These 
applications, documentation and training should be available to the field units that 
need them. It is not realistic nor good management practice to rely on the field to 
develop redundant data manipulation applications to satisfy Coast Guard wide 
requirements. 

Recommendation 1: Program managers should take a more active role in determining the 
data and applications requirements for their constituency. 

Recommendation 2: To avoid proliferation of unmaintainable locally developed 

applications, development software ( such as Pascal, Cobol and database software) should 
not be distributed with every system. 

K. CHANGING COST OF TECHNOLOGY 

Conclusion 1: ADP hardware prices have continued to decline as technology improves. 
Conclusion 2: Modifications to the standard terminal contract have allowed the Coast 
Guard to take advantage of price reductions and improved technology. 

Historically hardware prices have decreased as technology progressed. 
Technological improvements like more efficient memory or increased processor speeds 
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continually cause relatively new hardware to fall behind the state-of-the-art, and old 
hardware to become obsolete. 

A fixed price requirements contract for ADP systems hardware over a multiyear 
time period locks the Coast Guard into fixed prices for hardware as prices fall and the 
contracted technology falls further behind the power curve. Essentially paying more 
for less. This is particularly wasteful if the majority of the procurements under the 
contract occur in later years. The existing standard terminal contract has been 
modified to reduce prices for hardware and to replace older equipment listed in the 
contract with more current items. 

Recommendation I: A clause seeking periodic negotiated reductions in hardware prices 
corresponding to technology advances should be included in the contract if possible. 
Recommendation 2: Incentives should be offered to bidders to add or modify hardware in 
the contract as new technology becomes available and economically affordable. 

L. CONTRACT INTERPRETATIONS 

Conclusion: Inadequate acquisition documentation and contract specifications have left the 
standard terminal contract open to interpretations. 

At the time of the standard terminal contract award no formal contract 
document existed. 12 The contract was put together, after the award, from documents 
that existed on a word processor. C3, Incorporated, the successful bidder, did not have 
a contract until it was provided later. 

Significant contract interpretations have occurred since the -award in June 1981. 
Under the contract, procurement of hardware was to be allowed for 5 years. That 
would lead us to conclude that no procurement of hardware would be allowed after 
June 1986. However, since no equipment was actually accepted until September 1982, 
the current interpretation is that the procurement part of the contract will not expire 
until 5 years from that date, September 1987. 

Furthermore, the contract placed maximum order limits (MOL) on hardware 
which includes: keyboard/display (terminals), cluster controllers, direct access and tape 
storage devices, and printers. The differentiation between keyboard; display and cluster 
controllers has been lost. The standard terminal has the cluster controller capability 
built in. Because of the difficulty in attempting to differentiate between the two. the 
MOL for terminals was determined to be the sum of the MOL's for keyboard display 

12 Coast Guard Headquarters, interview with Office of Comptroller, Procurement 
Division (G-FCP) personnel, 21 June 19S6. 
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and cluster controllers. The interpretation extends to the delegation of procurement 
authority where the item cluster controller also appears. 

It is incredible to think that a contract of major importance to the entire Coast 
Guard could be subject to such major interpretations. The lack of acquisition 
documentation precludes further investigation into the original intent. Requirements 
for maintaining acquisition files should be strictly enforced to avoid similar situations 
from occurring. 

Recommendation: All relevant documentation should be required enclosures to the 

acquisition Jile to avoid possible adverse interpretation of future contracts. 
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APPENDIX A 
ACQUISITION PAPER 



{ taken from DOT Order 4200. 14B) 

1. Major System Identification. 

a. Description of the mission need to be satisfied. (A copv of the approved 
mission need statement should be attached to the AP) 

b. Name and brief description of the proposed acquisition program, 
including an explanation of how it will improve transportation. 

c. A plan and budget for obtaining alternative system design concepts or a 
justification, with supporting details, if alternative design concepts are not to be 
solicited. 

d. Identification of the key decision, under consideration. . Complete 
justification for waiving one or more key decision points should be included in 
this section of the AP. w 

2. Recommendation. Include a positive recommendation, i.e.. we should proceed 
with the acquisition described in this AP because (rationale supporting the 
recommendation). 

Program/Project Plan. This section of the AP should contain a summarv of the 
applicable program, planning documents and should cite the dates and other 
pertinent identifying data of each document. (Attach copies of the documents 
as appropriate ). Tins section of the AP should- also include: 

a. Details of initial program activities, including preliminary research, and 
studies, leading up to the AP under consideration. 

b. Summarv of projected program activities through completion or 
implementation. 

c. Status of prior and current svstems that have a relationship to, but are 
not part of, the major system described in the AP. Include anv known 
programs, projects, or svstems which are, or have been directed toward similar 
objectives. 

d. Acquisition cost estimates, by fiscal year, for each key decision phase. 
Indicate whether the estimate is in current vear or 'then year' dollars, and what 
inflation factors were considered in the estirfiate. 

e. Identification of the resources required from all sources, including in- 
house efiort. contracts, grants and interagencv agreements. Indicate theffime 
and costs of in-house efforts separately From’ out-of-house efforts (contracts, 
grants, etc.). 

f. Identification of Government or commercial facility needs which require 
special attention or approval. 

g. .Identification and evaluation of the major risks involved, including 
technical, budgetary and schedule, in achieving the goals of the proposed 
program. 

h. An identification of anv major operational cost, legal environmental, 
safety,, procurement or logfstical support requirements'' foreseen in the 
acquisition and proposed plans for satisfying these requirements. 

i. Indicate the extent of consideration given to and any approval obtained 
or required relating to the requirements of DOT 1370.2A. Procurement of ADP 
Processing Equipment and Services. 
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4. Acquisition Plan. This section should include, as a minimum, a discussion of the 
following items: 

a. Overall logistics strategy to put the system into operational use, including 
support requirements such as documentation, data collection, technical support 
services, spare parts, training, and maintenance, and installation. 

b. Procurement strategv including a discussion of the following factors for 
the phase under consideration: 

(1) Identification of all on-going and proposed contract efforts. This 
section should include a brief description of each contract award, 
estimated cost, period of performance, proposed method of procurement 
and contract type, anticipated award date, and contractor name {if 
known). 

(2) Procurement schedule, milestones and performance objectives. 

(3) A discussion of the consideration given to assuring competition 
and achieving an appropriate balance between contractor and 
Government risk. 

(4) A discussion of the feasibilitv of attempting cost sharing or 
otherwise providing contractors with' additional incentive to maximize 
accomplishment arid cost control. 

6. Schedule Goals. A projection of schedule goals for the program include 
procurement milestones including consideration" of the impact on contractors of 
delay, if any, between program pTiases. 

7. Economic Analysis, Cost-benefit/Cost Effectiveness Analysis, and Life Cycle Costs. 
Summarize the analyses previously undertaken and present a projection of life 
cycle costs for the program. 

A 

8. Special Funding Arrangements. Funds to be provided to, or received from, other 

Government or public agencies and private contractors (cost sharing, grants, 
etc.). 

9. Program Management. Designation of a program manager, and identification of 
the roles and functions of all organizations, principal officials and key personnel 
within and outside of DOT who have direct responsibility for performance of 
any of the work or for participating in anv of the decisions called for in the AP. 
A ' description of the proposed"" management control structure including 
personnel resources and skills required. “A copy of the program manager's 
charter shall be attached to the initial AP. 

10. Alternative Acquisition Actions. Briefly describe the alternative strategies {e.g. 
program delay, cancellation, etc.) considered by the Head of the Departmental 
element prior'to submission of the AP. 

11. Technical Alternatives. Briefly describe all known technical alternatives, and 
combinations thereof, that have been identified to date. This section should be 
very' broad in scope at kev decision one and should narrow in focus as the 
program progresses. 

12. Technical Addendum. This addendum, normally one page, lists the quantifvable 

operational and technical .{design) characteristics and the units or measure 
wnich best describe the transportation system, and which best refect its 
expected value and effectiveness in performing intended missions. This data 
shall be updated at each major decision point to show the current estimates for 
the delineated characteristics with . respect to earlier projections. Operational 
characteristics normally include reliability and maintainability goals (system or 
co mpo nent mean-time between failure" (MTBF) and mean- time to repair 
(MTTR)). Technical characteristics normally include those salient parameters 
which must be. achieved for the program to 'meet its objectives. Thev include, 
but are not limited to factors such as size, speed, weight, performance "envelope, 
etc. 
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13. 



Submission Procedures. 



a. Prepare 20 copies of the AP. 

b. Transmit these copies to the Executive Secretary using the following 
routing: 

To: The Deputy Secretary 
Through: TSARC (M-60), Executive Secretary 
[Ref. 5: Attachment 3] 
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APPENDIX B 

MAJOR SYSTEMS CANDIDATE MEMO 



(taken from DOT Order 4200.1 4 B) 

Major Svstem Acquisition Candidate: (Program Name) 

1. Brief statement of the mission need to be satisfied. 

2. Identification or required new capability, (this should be addressed in terms of 
functional capabilities desired and not in' terms of hardware solutions). 

3. Statement of benefit to the Government. 

4. Status of existing capabilities. 

5. Resource requirements, (including in-house resources, contracts, grants, 
interagency agreements, etc.) 

6. Time constraints. 

7. Status of current planning activities for the proposed program, (identifv anv 
contract dollars expended to date, if applicable) 

8. Recommendation as to whether the program should be designated as a major 
system acquisition. 

[Ref. 5: Attachment 1] 
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APPENDIX C 

MISSION NEED STATEMENT 



{taken from DOT Order 1400.I4B) 

I. Mission 

A. Mission Area. Identify the major transportation problem to be satisfied. 

B. Mission Task. State the mission need in terms of functional capabilities 
desired and not in terms of equipment or other means which might satisfy 
the need. 

II. Existing and planned capabilities to Accomplish the Mission Task. 

A. Briefly summarize the existing and planned capability and inherited assets 
to accomplish the mission. 

B. Departmental elements as well as other Government agencies involved. 

III. Assessment (with quantification, whenever possible). Assess the need in one or 
more of the following terms. 

A. Shortfalls in an existing capability. 

B. Technological opportunity. 

C. Physical obsolescence of equipment. 

D. Cost savings opportunity, potential for life cycle cost savings, etc. 

E. Other. 

IV. Constraints. 

A. Value or worth of meeting the need. 

B. -Relationship to overall agency budget. 

C. Relative priority within the mission area. 

D. Logistics considerations. 

E. Environmental considerations. 

F. Time Constraints. 

G. Maximum and minimum estimates of resources required. 

H. Other. 

V. Impact of staying with the Present System. 

A. Ability to fulfill the mission. 

B. Cost of increasins quantitv of existing equipment to a level that meets the 
capacity or capability needed. 

C. Cost of maintaining equipment with low availability or cost of ownership. 
[Ref. 5: Attachment 2] 
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APPENDIX D 

PROGRAM MANAGER'S CHARTER OUTLINE 

{taken from DOT Order 4200.1 4 B) 

A. Introduction. 

1. Purpose, 'Action Requested. 

2. Background. 

3. Approval. 

B. Charter. 

1. System Description. 

2. Scope of Project. 

3. Authorities. 

4. Responsibilities. 

5. Operating Relationship. 

6. Supporting Organizations. 

7. Organization and Staffing (including organization chart). 
[Ref. 5: Attachment 4] 
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APPENDIX E 

QUARTERLY STATUS REPORTS 

(taken from DOT Order 4200. 14B) 



1 . 

2 . 

*3. 

*4. 

*5. 

* 6 . 



7. 

8 . 

9. 

10 . 

11 . 



12 . 

13. 

14. 



15. 



Program Title: 

Report Period: 

Overall Assessment of Status: 

Evaluation of Technical Performance: 

Evaluation of Schedule: 

Evaluation of Cost: 

* for item numbers 3-6 above the following status codes are applicable: 
A - On tarset 

B - Management Attention 
C - Critical 

(Status code definitions are in Appendix ). 

Major Achievements in Last Quarter: 

Key Milestones 



Met: 

Missed: 



Key Milestones in Next Two Quarters: 

Financial Management Information. 

Key Problem Areas (discuss potential impact and corrective action planned): 

a) total program 

b) prime contract 

c) support contract(s) 

d) interfaces with other systems or equipment 
Meeting/Conferences/ Program Reviews 



Summarize kev meetings for (1) the report quarter, indicating purpose, 
attendance and results; and (2) the next 2 quarters, indicating purpose and 
attendance. 



Life Cycle Costs 

Assess anv events since the previous Quarterly Status Report which might 
significantly affect the life cycle costs. 

Assessment of the estimate to complete the current program: 

a) total program 

b) prime contract! s) 

Prime contract! s) changes 
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Number of contract changes approved in the current quarter 

amount . 

Number of contract changes submitted in the current quarter 
approved . 

Estimated dollar amount 



Submitted by: _____ 

Program Manager Date 

Approved by: 

Administrator Date 

[Ref. 5: Attachment 6] 



, Dollar 
but not 
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APPENDIX F 

STATUS CODE DEFINITIONS 



( taken from DOT Order 4200. 14B) 

The following criteria provide more specific guidelines for identifying when a program 
is significantly off target. 



On-target Status 

1. Not more than 10 percent off budget as reflected in the operating plan. 

2. Within 3-4 weeks of meeting major nonpublic milestone dates (milestones to 
which the Secretary has not publicly committed the Department). 

3. Making acceptable progress toward achieving objectives and performance 
measures, arid indicating that tins satisfactory performance will continue. 



Management Attention Status 

1. Between 10-20 percent off budget as reflected in the operating plan. 

2. Between 1-3 months of meeting major nonpublic milestone dates. 

3. Results indicate program may not be able to achieve desired objective and 
performance measures. 

•4. Although current status is still on target, a situation is developing that will cause 
problems in the future. 



Critical Status 

1. Over 20 percent off budget as reflected in the operating plan. 

2. More than 3 months behind meeting major nonpublic milestone dates or behind 
any milestone to which the Secretary has publicly committed the Department. 

3. Results to date show' the program will not meet desired objectives and 
performance measures without budget of legislative relief. 



No action required. 



The Assistant Secretary for Budget and Program shall advise the Acquisition 
Executive as appropriate. 

[Ref. 5: Attachment 6] 
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APPENDIX G 

AGENCY PROCUREMENT REQUEST 



{taken from FIRMR Sec. 201-23.106-2 ) 

1. Agency Information: Provide agency name, address, and location where 

equipment will be installed or services will be performed. Provide names and 
telephone numbers of appropriate technical and contracting officials. Identify 
the position title and organization identity of the official authorized to conduct 
the acquisition. 

2. Project Title and Description: 

a. Provide the project title and a brief but specific description of the primary 
agency program(s) that the ADP equipment will support. 

b. Provide a brief but specific description of the current major system 
components (including ADPE configuration) or services supporting the 
program(s). 

c. . Provide a brief but specific description of the major svstem components or 
services to be acquired during the svstems life of the requirement. ..The 
delegation resulting from this submission will be limited to resources described 
herein. 

3. Acquisition Strategy: 

a. Indicate whether or not the proposed procurement approach is to satisfy 
a requirement using a specific make and model specification; whether 
compatibilitv limited'' requirements will be used on either a mandatory or 
nonmandatory basis; and specify the type of contract expected to be used. 

b. Identify bv fiscal vear quarter the following planned milestones: Release 
of solicitation document and contract award. 

c. If the request involves a pilot or prototype, the strategy for the follow on 
implementation phase must be described. 

d. , . Indicate whether the acquisition plan contemplates contracting ... under 
policies and procedures for: 

(1) Full and open competition 

(2) Full and open competition after exclusion of sources; or 

(3) Other than full and open competition. 

4. Estimated Contract Life and Cost: The estimated contract cost of the acquisition 
(not the overall svstem life cost) shall be identified bv tvpe of request for the 
contract life and shall include all anticipated optional quantities, services, and 
periods...! he estimated contract cost should correspond to the planned contract 
life. The delegation of authority resulting from this submission will be limited 
to quantities alid years described herein. 

5. Regulatory compliance: 

a. (1) Provide a statement which indicates that the agencv has reviewed and 
complied (or will comply) with all applicable regulations, or 
(2) List those deviations to 'the regulations that applv to this requires for 
which approval is sought and provide an explanation for each 
regulatory deviation request. 

b. Provide the date of completion or most recent update of the following 
documentation, or indicate if not applicable: 

(1) Requirements analysis 
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1 2) Analysis of Alternatives 

3) Performance evaluation for the currentlv installed ADP system 

4) Findings to support the use of compatibility limited requirements 

5) Software conversion study 

6) Certified data to support a contemplated requirement available from 
onlv one responsible source 

(7) Certified data to support a contemplated requirement using a specific 
make and model specification 

(8) Description of those planned actions necessary to foster competition 
for subsequent procurements 



6. Agency remarks: Provide additional information deemed necessary concerning 
anv of the above items or special conditions associated with this procurement; 
e.g'., required building construction/modification by GSA. 

7. Agency/ GSA references: Provide references to previous GSA authorizations; 
meetings, telephone discussions, etc. 

8. Agency authorized signature, position title, organizational identity, date. 

[Ref. 9: Section 201-23.106-2] 



70 



APPENDIX H 

DETERMINATION OF NEED AND REQUIREMENTS ANALYSIS 



{taken from FIRMR Sec. 201-30.007) 

As a minimum, the agency shall consider the following factors in the requirements 

analysis: 

1. The information processing functions that must be performed. 

2. The agency applications, information resource svstems, and components 
involved, their physical locations, and operational constraints. 

3. The problem that will be solved by acquiring new or additional equipment, 
systems and/or software. 

4. The nature of the data or information to be generated, transmitted, or stored on 
the proposed equipment or system, who will maintain it, and who will require 
access to it. 

5. The feasibility of sharing, using reassigned or excess Government-owned or 
-leased equipment, the off-loading of lower priority applications, using Federal 
data processing centers and GSA sources of supply, using commercial ADP 
services, or il~ applicable, increasing the capability and productivity of the 
existing system. 

6. The probable improvement in operational effectiveness and the economies that 
will be realized from acquiring new or additional equipment, systems, and or 
software. 

7. Space management considerations; e.g. heat dissipation, air flow, temperature 
range, relative humidity, energy conservation, power supply, cables, including 
coordination with building managers and GSA. 

8. The present and projected workload in terms of: 

i. Svstems life; 

ii. Data entry and associated telecommunications support; 

iii. Data base' and data base management; 

iv. Data handling or transaction processing by type and volume; 

v. Output needs~and associated telecommunications support; 

vi. Expandability requirements; and 

vii. Privacy and security safeguards. 

9. A performance evaluation of the currently installed ADP system to provide a 
baseline for evaluation of proposed alternatives for meeting the data processing 
needs. 

10. The risks over the svstems life of adverse impact on agency missions bv 
acquiring insufficient 'ADPE capacity versus the extra costs' of acquiring 
excessive ADPE capacity. 

11. The appropriate performance and capability validation techniques that should be 
employed in the acquisition. 

[Ref. 9: Section 201-30.007] 
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APPENDIX I 

COMPATIBILITY LIMITED REQUIREMENTS 



{taken from F1RMR Sec. 201-30.009-3 ) 

The following factors shall be considered in determining whether the incorporation of 

compatibility limited requirements is justified for the augmentation or replacement 

acquisition: 

1. The essentiality of existing software, without redesign, to meet agencv critical 
mission needs'; e.g., the ‘'continuity of operations may be so ‘"critical that 
conversion is not a viable alternative. 

2. The additional risk associated with conversion if compatibility limited 
requirements are not used and the extent to which the Government 'would be 
injured, financially or otherwise, if the conversion to the new ADP system fails. 

3. The additional adverse impact of factors such as delav, lost economic 
opportunity, and less than optimum utilization of skilled professionals if 
compatibility limited requirements are not used. 

4. The steps being taken to foster competitive procedures in the augmentation or 
replacement acquisition. 

5. The off-loading of selected applications programs to commercial data processing 

service facilities as an alternative to conversion. 

6. The continuation of ADP services for selected application programs with the 
present commercial ADP services contractor as an alternative to conversion of 
all programs in the present ADP resource system. 

7. The extent of essential parallel operations; i.e., the need to continue operation of 

the old svstem in parallel with the new svstem until the new svstem can fully 
support the mission needs. 

8. The feasibility of competing conversion requirements to be performed on a 
guaranteed basis under a solicitation that couples the conversion effort and 
ADP services in a single contract, including consideration of the basis for a 
calculation of liquidated-damages provisions for conversion performance failure. 

[Ref. 9: Section 201-30.009-3] 
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APPENDIX J 
SELECTION PLAN 



{taken from DOT Order 4200.11 A) 

The Selection Plan should include the following: 

a. A brief description of the product or service to be procured; 

b. The date of approval of an applicable Acquisition Paper covering the proposed 
procurement; 

c. Identification of any closely related procurements or planned procurements; 

d. A brief description of those areas of the procurement which are believed to 
represent significant technical, schedule, or cost risks; 

e. Nominations for stalling of the SEB bv individual name. Indicate each 
nominee's field of specialization and job title. Ensure each nominee will be 
available to serve on the SEB before submitting the Selection Plan; 

f. An estimate of the total procurement cost and a statement of availabilitv of 
funds; 

g. A statement of significant procurement considerations, including, the proposed 
contract tvpe, identification of option items, anticipated period of performance, 
funding method, and and unusual contract clauses that are contemplated; 

h. Identification if the product or service to be procured will be the basis for future 
standardization; 

i. A proposed milestone schedule of events leading up to contract award; and 

j. Any other information warranting the SSO's attention. 

[Ref. 11: pp. 1-1,2] 
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APPENDIX K 

REQUEST FOR PROPOSAL 



(taken from DOT Order 4200.1 1 A) 



In determining the RFP's acceptability, for evaluation purposes, the SEB should assure 

that it provides the following: 

a. A statement of work accurately describing the product or service to be procured. 

Further, the statement of work should be consistent with the approved 
Selection Plan and anv applicable Acquisition Paper. If the acquisition, is a 
major svstem subject to the requirements of DOT 4200. 14A and the approved 
AP provides for the solicitation of alternative system design concepts, the 
Government's requirement should be stated in terms of mission need so that 
industry can respond with alternative system design concepts to satisfy the 
mission need and propose their own 'technical approach, design features, 
subsystems, and schedule and cost goals. 

b. A statement as to whether or not a pre-proposal conference is contemplated. If 
a ore-proposal conference is to held, state when and where and advise the 
offerers that questions to.be discussed at the conference must be submitted in 
writing by a specified number of days prior to the conference. Sufficient time 
must Be permitted for potential olfe'rers to review the RFP prior to anv pre- 
proposal conference. 

c. Description of the desired proposal format. 

d. Description of the tvpe of contract that is contemplated, i.e.. cost reimbursement 
or fixed price, and anv special incentive or cost participation features. The RFP 
should include a notice that although a particular tvpe of contract is 
contemplated, the Government may determine after evaluation of proposals, 
that another type of contract is more appropriate and may award on that basis 
without soliciting new proposals from ail offerers. 

e. Clear and concise statement of the basis on which the award will be made. This 
should be followed by: 

(1) Complete description of the technical evaluation criteria. The technical 
evaluation criteria should be listed in descending order of importance 
with an indication, in some narrative manner, of their relative 
importance. 

(2) Description of the business/management evaluation criteria. 

(3) Description of any other evaluation criteria established by the SEB, e.g. 



cost. 



f. When ’ state i 

awards „ de. 

g. Proposed contract clauses. 




state the number of awards contemplated or that multiple 



[Ref. 11: pp. IV- 1,2] 



74 



LIST OF REFERENCES 



1. U.S. Coast Guard. Commandant Instruction M3090.2(under development), Coast 
Guard Standard Terminal Management Plan, 24 August 1983. 



2. U.S. Coast Guard. Commandant Instruction M3090.1, Coast Guard C3/IRM 
Plan, 25 May 1984. 



3. U.S. Coast Guard, Contract DTCG23-81-D-30067, Standard Terminal Contract, 
29 June 1981. 



4. U.S. Coast Guard. Commandant Instruction M 16010. 1A, Planning and 
Programming Manual , 2 December 1983. 



• 5. U.S. Department of Transportation, Order 4200. 14B, Major Systems Acquisitions 
Review and Approval, 6 January 1983. 



6. Office of Management and Budget. Office of Federal Procurement Policy, Major 
System Acquisitions, A Discussion of the Application of OMB Circular No. A- 109, 
August 19/6. 



7. Federal Acquisition Regulations System, 48 CFR Chapters band 12, Revised as of 
1 October 1985. 



8. U.S. Department of Transportation. Order 4200. 9A, Acquisition Review and 
Approval, 29 August 1978. 



9. General Services Administration. Office of Information Resources Management, 
Federal Information Resources Management Regulation, 1 May 1984. 



10. U.S. Department of Transportation, Order 1370.6A, Automated Data Processing 
Policies, 8 October 1979. 



11. U.S. Department of Transportation, Order 4200. 11A, Source Selection, 18 
October 1981. 



12. U.S. Department of Transportation, Order 1370.9, Policy and Guidelines for 
Determining the Need for Ltilization of Automatic Data Processing Resources, 5 
April 1977. 



13. U.S. Coast Guard, Commandant Instruction M5230.26, Small Information 
Resources Management (IRM) Systems Acquisition Documentation, 17 July 1985. 



14. U.S. Congress, Committee on Armed Services of the House of Representatives, 
Laws Relating to Federal Procurement (As amended through Februarv 2S, 19S6), 
10 U.S.C. S5.1622, 99th Cong., 2d sess.. 19S6. 



75 



15. U.S. Coast Guard, Office of Command, Control and Communications, Report : 
Managing End User Computing One Agency’s Approach , 28 May 1984. 



76 



BIBLIOGRAPHY 



American Management Svstems, Inc, U.S. Coast . Guard Standard Terminal 
Replacement Cost Analysis, Comparative Cost Analysis, Arlington, VA, 27 May 1986. 

Competition in Contracting Act of 1984, Statutes at Large, PL 98-369, 18 July 1986. 

Computer Science Corporation, Thirteenth District United States Coast Guard 
Computer User Survey 1985, Silverton, WA, 23 October 1985. 

Electronic Data Svstems Corporation. Thirteenth District United States Coast Guard 
Standard Terminal' Survey, Bremerton, WA, 29 June 1984. 

Federal Computer Performance Evaluation and .Simulation Center, Fedsim Report 
85014-02-DOT, Functional Requirements for the U.S. Coast Guard Standard Terminal, 
Alexandria, VA, April 19S6. 

General Accounting Office, (AFMD-8 1-104), Non-Federal Computer Acquisition 
Practices Provide Useful Information For Streamlining Federal Methods, 2 October 1981. 

General Accounting Office, (RCED-85-144), GAO's Analysis of Audit and Investigative 
Reports Concerning~U.S. Coast Guard Procurement, 16 Jufy 1985. 

General Services Administration. Office,. of Information Resources Management, 
Solicitation Document for A DP Equipment Systems, Revised through Change 7. 

Office Of Management and Budget, Circular No. A- 109, Major System Acquisitions, 5 
April 1976. 

Office of Management and Budget, Circular. No. A-130, OMB Circular on the 
Management of Federal lnformation'Resources, 12 December 1985. 

U.S. Coast Guard, Coast Guard Acquisition Process Study, September 1985. 

U.S. Coast Guard, Source Evaluation Board Report, Standard Terminal Procurement, 8 
June 1981. 

U.S. Coast Guard, Standard Terminal Study Report, 21 July - 21 August 1982. 

U.S. Coast Guard, Commandant Instruction M5230.8A, Coast Guard A DP Plan, 7 
April 1980. 

U.S. Coast Guard. Commandant Instruction M5233.3, Coast Guard ADP Management, 
4 September 1980. 

U.S. Coast Guard. Commandant Instruction 5230.24, Information Resources 
Management (1RM) System Acquisition Authority, 27 September 1983. 

U.S. Coast Guard, Commandant (G-Tt) Memorandum 10550, Standard Terminal 
Acquisition and Support Plan (ASP) Review Board Meeting, 29 May 1986, 9 May 1986. 

U.S. Coast Guard. Commandant Notice 4200, Coast Guard Competition Advocate 
Program, 16 March 1986. 

U.S. Coast Guard, Commandant Notice 5233, Computer Terminal Procurements, 11 
June 1979. F 

U.S. Coast Guard, Commander Seventeenth Coast Guard District (dt) letter 5230, 
Standard Terminal Working Group (STWG), 2 December 1985. 

U.S. Department of Defense, Directive 5000.1, Major System Acquisitions, 29 March 
1982. 



77 



U.S. Department of Defense, Directive 7920.1, Life Cycle Management of Automated 
Information Systems {A IS), 20 November 1979. 

U.S. Department of Defense, Directive 7920.2, Major Automated Information Systems 
Approval Process, 20 October 1978. 

U.S. Department of the Navy, SECNAVINST 5231. IB, Life Cycle Management {LCM) 
Policy and Approval Requirements for Information Systems (IS) Projects, o March 1985. 

U.S. Department of the Naw, Automatic Data Processing Selection Office, 
ADPSOINST 4325, Contracting for Automatic Data Processing Equipment ( ADPE ), 29 

U.S. Department of the Naw, Naval Data Automation Command. NAVDAC Pub. 

24.1, Saw Data Automation Management Practices and Procedures : Systems Decisions, 
9 March 1983. 

U.S. Department of the Navy, Naval Data Automation Command, NAVDAC Pub. 

24.2, Saw Data Automation Management Practices and Procedures : Systems Decisions, 
9 March 1983. 

U.S. Department of the Navy, Naval Data Automation Command. Small Computer 
Guideline, Acquisition and Management of Small Computers, March 1984. 

U.S. Department of Transportation, Office of the Inspector General, Report No..AV- 
CG-4-0U7, Report on Procurement of Automated Data Processing Equipment, United 
States Coast Guard, 24 January 1984. 

U.S. Department of Transportation, Office of the Inspector .General, Report^ No. 
Rl-CG-4-109. Report on Audit of Independent Microcomputer Systems, United States 
Coast Guard, 28 September 1984. 

U.S. Department of Transportation, Order 1370.8, Planning and Reporting Procedures 
for Automatic Data Processing Equipment and Services, 17 January 1975. 

‘U.S. Department of Transportation, Order 1370.10, Management of Automated Systems 
Development and Operation, 5 April 1977. 

Wilson Hill Associates. Inc., Standard Terminal Software Conversion Studv, Final 
Report, Washington, DC, February 1986. 



78 



INITIAL DISTRIBUTION LIST 



1 . 

2 . 

3. 

4. 



5. 



6 . 

7. 



8 . 



Defense Technical Information Center 

Cameron Station 

Alexandria, Virginia 22304-6145 



Library. Code 0142 
Naval “Postgraduate School 
Monterey, California 93943-5002 



Commandant (G-PTE) 
U.S. Coast Guard 
2100 Second Street. SW 
Washington, DC 20593 



Commandant (G-TDS-1) 
U.S. Coast Guard 
2100 Second Street. SW 
Washington, DC 20593 



Professor Norman R. Lyons, Code 54LB 
Naval Postgraduate School 
Monterey, California 93943-5000 

LCDR Ravmond W. Smith, Code 54SX 
Naval Postgraduate School 
Monterey, California 93943-5000 



LT James D. Maes 
Commandant (G-TDS) 
U.S. Coast Guard 
2100 Second Street. SW 
Washington, DC 26593 

Dr. Joseph Discenza 
c'o Wagner Associates 
27 West Queens Way 
Suite 301 

Hampton, Virginia 23669 



No. Copies 
2 



2 



2 



2 



1 



1 



1 



1 



79 



DUDLEY KWOX LIBBAB-Y 

HA V. { ' : f^B r y :t B AD'U v-.-TE SCHOOL 
MOHT'iiirlIi s i , OALij’CiflillA 93843-5002 



Thesis 

M274885 Maes 

c • 1 A study of the U.S. 

Coast Guard standard 
terminal acquisition 
process . 



13 JAN a 9 
3 MAY 39 
1 ? i*. A 3 q i 
:? KV J o\ 



3 2 9 8 7 
^ 7508 



Thesis 

M274885 Maes 

C '\ A study of the U.S. 

Coast Guard standard 
terminal acquisition 
process . 




ihesM274885 

A study of the U.S Coast Guard standard 



3 2768 000 72749 9 

DUDLEY KNOX LIBRARY 










